[syslinux] Comments WAS: Refactor checksize.pl

[Ady]

> >
> > 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, and the 
change we are referring to is a command line parameter, which means it 
is part of the way a "user" (which I am using here as a generic term, 
not necessarily a final non-developer physical individual) interacts 
with the code. I also added, more than once, the general scope of my 
comments, as opposed to taking the very specific case of this 
particular Perl script. Reading the complete email (for context) is 
relevant.
 
> >
> > 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; after all, the location of binary files in 
prior versions is "legacy" too, and it doesn't affect the compilation 
of the new resulting version. And yet, it had (and still has) a clear 
impact on "users" (and by "users" I don't just mean final users, but 
rather package maintainers, other scripts, common users, and more).

> > 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.
> 
> These projects are completely unrelated to syslinux. Should someone
> use our checksize.pl, he would probably copy it to his repository. As
> I said, this script isn't shipped to the user. The only purpose of
> this script compared to the standard command "truncate" is that it has
> several default size recorded depending on the file name pattern and
> fail if the file is already too large.
> 
 
My "PS" in my prior email is/was not directly related to the Perl 
script, nor to the specific patch (thus, it was written after my 
signature, as a "PS"). It was about the generation of the "*mbr*.bin" 
files (which is the goal of the Perl script in question). Mentioning 
those projects is a way of inviting the potential investigation (by 
developers) of alternative ways of delivering MBR (and VBR) files and 
their installers in Syslinux.

> >
> > 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.
> 
> This script just extend the file to the size of the boot sector and
> fail if it's too large. Nothing more. It has very little to do with
> the installers.
 
The current installers include "ldlinux.*", which makes the them 
version-dependent. If the "real" installation code were to be 
separated, and the "ldlinux.*" files were to be arguments of such 
hypothetical alternative command line installer(s), we could have 
installers that could be independent of the version. It could simplify 
several situations / use-cases (while making other cases more complex), 
and in some cases it could even reduce the resulting size for users -- 
incidentally, I wrote about this matter in irc #syslinux just a few 
days ago. Again, this was part of a "PS", not directly related to the 
original patch.

> 
> Don't try to invent new use cases or new goals for the Syslinux
> project.We provide a set of boot loaders and installer for those boot
> loaders. Not a set of tools to help people make their own boot
> loaders.
 
The interaction with (other) code / users, either within or outside of 
The Syslinux Project, is the relevant point I was trying to make. This 
seems to be one of those different points of view between developers 
and users (including maintainers of packages and of generic 
installation methods in several distros); we see things with a 
different perspective.

> 
> 
> Celelibi
 
 
Regards,
Ady.

> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>