[syslinux] Comments WAS: Refactor checksize.pl

dave madsen dcmdcm at gmail.com
Fri Nov 20 23:29:24 PST 2015


On Fri, Nov 20, 2015 at 2:09 PM, Celelibi via Syslinux <syslinux at zytor.com>
wrote:

> 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



Yes, it IS a UI.

The reason it's a UI is because *every* function and option exposed on the
command line IS the "user interface".  Debugging switches, arcane and
deprecated functionality... EVERYTHING.  It DOES NOT MATTER whether it's
part of your "production" or merely support code inside the project.

It was suggested that no new use cases or goals for the Syslinux project be
invented.  I'm telling you:  it's too late, your customers have already
done that without your permission!  I can guarantee that for every weird
switch or piece of functionality in an executable, there's SOMEONE out
there that's used (or abused!) it and depends on it working the way it
does.  And if you change or remove it without warning, it will break
whatever they're doing.

My personal opinion is that the audience that uses Syslinux tends to be
more clever and investigative than "normal".  To me, this means that you
need to be even more cautious before you change ANYTHING that might affect
them because someone's probably used it in some twisted nasty unexpected
way.

I believe that Ady has already suggested that various changes made in the
past -- that were made with good intentions, remember! -- had negative
effects.  (Ady, if I'm misinterpreting your meaning, please yell at me!).

Ideally, a project should have a standard way of dealing with proposed
changes that would affect ANY existing behavior.  Maybe it's a timeline for
deprecating what's current and then eventually making the proposed change.
Or some way to warn your "customers" that something's gonna change soon.
Maybe you make the change but also support an older version with the
behavior intact so your users have a chance to adapt.  Maybe you just
create documentation in big letters that says what's subject to change
without warning and what's not so they know if they're on shaky ground or
not.

I know that I've earlier seen on this list instances of people that said
they're still using older Syslinux versions because there was some change
in later versions that affected them badly and they didn't have a chance to
adapt.

I don't know what's right for the project, as I'm not a developer on it.  I
do know that manpower is short -- a reason to be even more cautious because
the resources that have to deal with "why did you break this?" complaints
are already stretched thin.

I've worked on other software, and learned the hard way that people are
endlessly creative and WILL use something you've created in unexpected
ways, and when you change something you know "that nobody still uses" or
"it's internal" or "it's undocumented", you will find that "nobody" on the
phone calling you one day to yell at you, probably sooner than later.

One of the differentiators between a private project with very few
close-knit users and a public project with many disparate users is the way
change control is handled.  What you do affects other people.  A motto I've
always tried to follow is: "No bad surprises!"

Don't abuse your customers by unexpectedly changing behavior without
warning -- even for "internal-only" executables.

OK, I've jumped off my soap box.  I'll go back to lurking again.  If I've
said anything wrong or offensive, feel free to say so (heh, I don't think I
can stop you).


More information about the Syslinux mailing list