[syslinux] Comments WAS: Refactor checksize.pl

[Celelibi]

2015-11-20 12:50 UTC+01:00, Ady via Syslinux <syslinux at zytor.com>:
>
>> 2015-11-20 8:15 UTC+01:00, Ady via Syslinux <syslinux at zytor.com>:
>> >> >
>> >> > I don't like the idea of changing "UI" (e.g. command line options
>> >> > that
>> >> > might be used by some users) without very well-thought reasoning.
>> >>
>> >> This is not an UI. AFAIK, this script is not shipped to the user. I
>> >> don't even see what a user could do with it.
>> >>
>> >>
>> >
>> > Well, the Perl script _is_ shipped in the official release
>>
>> My bad. I only checked the debian packages, none of them include a
>> file named checksize.pl.
>> I just checked the official release, it actually include the whole
>> source tree. Does that mean we can't change any argument of the shell
>> or perl scripts or any target of the Makefiles?
>> Of course not.
>>
>> >
>> >> >
>> >> > In the particular case of "padsize" vs. "maxsize" (options /
>> >> > parameters
>> >> > of the Perl script), there used to be a separate use of them.
>> >> > Although
>> >> > there _seems_ to be no use for having both of them simultaneously at
>> >> > this time _for a normal build of Syslinux_, we cannot discard /
>> >> > disregard the possibility that some script in some distro might want
>> >> > to
>> >> > take advantage of each of them independently, especially for some
>> >> > debugging situation (e.g. some buggy / old BIOS).
>> >> >
>> >> > Another potential (hypothetical) use-case might be some "bootable
>> >> > USB
>> >> > tool" making use of some/many/all parts of the Syslinux code. Let's
>> >> > not
>> >> > forget that some distros are still using older versions of Syslinux
>> >> > (even v. 3.xx), and (unnecessarily) changing command line options
>> >> > makes
>> >> > the updates (unnecessarily) more difficult, generally speaking.
>> >>
>> >> Keeping some legacy in the compilation chain for a potential usage
>> >> we're not even aware about seems a bit insane. If someone play with
>> >> the syslinux's internal compilation process, he is probably aware that
>> >> it may change completely on every single commit. We just do not
>> >> support this usage.
>> >>
>> >
>> > The example I gave (moving the location of binary files) could also be
>> > included in such category;
>> No.
>> I specified "in the compilation chain". Because this script is only
>> this: one tool used to build the binaries. Same would go for the
>> following files:
>> - efi/wrapper.c
>> - lzo/prepcore.c
>> - core/lstadjust.pl
>> - utils/bin2hex.pl
>> - **/*.pl
>>
>> They're all just some custom tools when a single shell line in the
>> Makefiles would be too clumsy.
>>
>>
>>
>> Best regards,
>> Celelibi
>
>
> I seem to be failing to express my point clearly. I'll try one last
> time.
>
> My comments were generic, not specific to the patch, nor to the Perl
> script.

I understand your recurring point "don't break the UI". But it's not
applicable here because it's not an UI.


Regards,
Celelibi