[syslinux] Comments WAS: Refactor checksize.pl

Ady ady-sf at hotmail.com
Fri Nov 20 03:50:26 PST 2015


> 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.

Previous proposed patches (before the one about the checksize.pl 
script) sent by Nico don't seem to have interaction with external 
factors (although, there was at least one factor that was taken in 
consideration in a later commit, after I brought it up in irc 
#syslinux). If I am not mistaken, dependencies (e.g. mtools) and (root) 
privileges were not changed in prior proposed patches, neither 
parameters used in scripts nor user input.

Being part of the arguments of the current normal procedures for 
building Syslinux (whether in use or not), or some optional script, or 
some file location, are some of the many examples in which there is 
some kind of interaction (between scripts, users, third-party 
tools...).

The proposed patch for the checksize.pl script changes the potential 
arguments. In the current context of these comments, which are 
_generic_, I do not care whether the code is improved, nor whether the 
optional parameter that was eliminated was not being normally used in 
the current building steps. The only thing I am focusing on in my 
present comments is that there is some kind of interaction, and that it 
is being changed.

The assumption that "something is not really being used so let's 
simplify it by eliminating it from the code" is frequently not 
evaluated to its fullest, and finding that such elimination was not 
%100 adequate usually takes a lot of effort, including from common 
users testing the results. When the elimination of code affects some 
kind of interaction, the effects are even more difficult to predict, 
and therefore the eventual correction needs even more resources. 
Instead of "elimination", the action could had been any kind of change 
related to any kind of interaction, and the main point of my comments 
would have been the same. I am going to say it again: this is a generic 
comment, not specific to the patch nor to this Perl script in 
particular.

Some code that is "so clear that it can be improved in a certain 
manner" for one developer at a certain time / moment might not be so. I 
can give many examples, including a very recent one in the Syslinux 
development, but that's besides my point.

Considering that:
_ Nico is new to the code; and that,
_ there are very few developers that actually have enough experience 
with different (use) cases with the storage-related installers in 
Syslinux; and that,
_ beta testers in Syslinux are also very few; then...

... I decided to comment about what _I_ consider a potential 
interaction. I am well aware that developers might have a different 
point of view, and therefore I express this concern of mine _now_. For 
instance, if someone would had expressed similar concerns when the 
binaries where moved to the "bios/" sub-directory, _perhaps_ the 
negative comments and strong complaints (and many, many problems) such 
move caused (and still causes) _might_ had been re-evaluated. Maybe the 
resulting decision would had been the same, or maybe not, or maybe the 
move would had been much better communicated, or maybe package 
maintainers would had been consulted for suggestions, or...

There are other cases of interaction changes that brought some degree 
of headaches; the "offset" parameter or the use of "-i" for installers 
are just 2 of them, which I mention because they are clear examples. 
Other examples were seemingly not so clear at the time, but impact they 
had.

I took this opportunity to express a _generic_ comment / concern, and I 
do it when it might count for something, before it might be too late. 
We are all genius after the fact, right? Whether this particular 
suggested patch could have a minor impact, a greater one, or none at 
all, is not my main point. After all, the main Syslinux's developers 
will decide.

So, the replies to my comments are being "too-specific", related only 
to the specific patch, or to the specific current use of the script, as 
if I had made my comments in direct relation to the particular patch. I 
don't think I expressed it in such way, and I clearly mentioned the 
"generality" of my comments several times in all my posts in this email 
thread. The patch was only a trigger, an excuse, an oportunity.

I think I'm done with the matter.

Regards,
Ady.

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




More information about the Syslinux mailing list