[syslinux] boot... round 2

[Ady]

> 
> Are there any more questions, "Inspector Clouseau"? :)
 
 
Really? Let's be serious. During this email thread, several posters have expressed 
that the information / feedback being provided seems somewhat unclear / confusing / 
inaccurate. I am asking specific questions so to receive more accurate / clear / 
specific answers.

For the sake of the Syslinux Mailing List, which is not about Fedora-only builds 
(nor its patches, nor its packages), there is no "syslinux-6.04-pre1" yet (and, 
IMHO, should not be yet). Everyone else is Free to use whatever nomenclature would 
like, except the one that exactly matches the naming convention of The Syslinux 
Project distribution archives.

Regarding your suggested patch, which consists in reverting a prior commit, it may 
solve your case (or Fedora's needs), but it is not adequate for The Syslinux 
Project. Although I am *not* speaking officially for The Syslinux Project, I am 
using plain simple clear (blunt) language, so there is no possible confusion 
regarding the opinion I am expressing.

Having said that, no one is denying that something about the original commit 
*might* need some correction, or that there *might* be something else to correct in 
the Syslinux source code when building it with gcc v.5+. There might be, yes.

But, aside from the specific code you are suggesting (and considering that I am not 
qualified to comment about it), there seems to be something wrong in the logic (at 
least, as I understand the less-than-%100-clear information posted).

If the same (original, not with your suggested patch) code works from CLI, and also 
when using menu.c32, then it is only the combination with vesamenu.c32 that 
triggers some kind of failure. Reverting a prior commit that solved a problem with 
a specific directive (or at least, attempted to solve it) does not improve the 
code.

IMHO, the adequate way to solve the problem is finding why vesamenu.c32 triggers a 
problem when it is compiled with gcc v.5+.

Reverting a commit that is (only) related to the SYSAPPEND directive just because 
it happens to trigger a problem with vesamenu.c32 under some specific environment 
would be like reducing car accidents by forbidding cars from being drove on the 
streets at all.

If some part of the code *triggers* some problem, let's find out what's the real 
source of the problem (and solve it), instead of getting rid of the trigger.

Regards,
Ady.