[syslinux] Comments WAS: Refactor checksize.pl

[Ady]

> 2015-11-19 17:30 UTC+01:00, Nicolas Cornu via Syslinux <syslinux at zytor.com>:
> > - Remove padsize argument as it is never used.
> > - Add an usage printed when $file is not set or --help, -h
> >   is the first argument.
> > - Add basic tests for this script.
> > ---
> >  mbr/checksize.pl      | 27 ++++++++++++++++++---------
> >  mbr/checksize_test.sh | 22 ++++++++++++++++++++++
> >  2 files changed, 40 insertions(+), 9 deletions(-)
> >  create mode 100644 mbr/checksize_test.sh
> >

> Just to make sure: the goal of the shell script is to check the perl script?
> If so, I wonder if it wouldn't be better in the test directory if it
> is needed at all. I'll let the others comment on that.
> 
> I agree with your simplification of checksize.pl, but have you
> searched through the history to see if there wasn't a good reason to
> separate maxsize and padsize?
> 
> 
> Celelibi
 
For what my personal opinion might be worth...

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.

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.

I am not against changing code, but, as common user, I differentiate 
between "internal-only" code and code that "interacts" with users. I 
don't know how much this particular suggested change is necessary / 
desired, and of course I don't know how much it would potentially 
affect third-party tools / users; these comments are more general than 
this particular email thread.

Example: the "simple" change (since Syslinux v.6.xx) of the location of 
binary files (such as "mbr.bin") by moving them to the "bios/" 
sub-directory tree has had a clear impact on third-party tools and 
distros; most common users (and more-than-one developer / maintainer of 
third-party tools / packages) have a negative view / opinion regarding 
this change of directory.

BTW, let's not forget the existence of the "diag/*" files in Syslinux.

Regards,
Ady.
PS: Let's also not forget the existence of other methods / code to 
generate / install MBRs and/or VBRs such as:
 _ "sys.com" / "sys.exe" (v.3.8) from FreeDOS;
 _ "sys-freedos-linux";
 _ "ms-sys" ( _code in C_ ) and its forks such as:
  _ "ms-sys-free" (current latest code is older than its parent);
  _ a fork of "ms-sys" by Pete Batard (used in RUFUS) with additional 
recent patches.

Common users and third-party scripts might rather use the Perl script 
for simplicity, so having scripts available is helpful. Having code 
written in C for the generation / installation of MBRs / VBRs might be 
(at least in part, or as a first step) an alternative to the generation 
of the current syslinux / extlinux installers, and/or eventually an 
alternative installation method.