Syslinux - Sep 2015 - gnu-efi submodule WAS: efi: Makefile improvement

> >>>
>  > How about
>  > 1) Laying every needed versions of gnu-efi under its own directory
where
>  > its name could be just the version.
>  > 2) Defining the gnu-efi version to use in a Makefile variable; if the
source
>  > is not present then the Makefile triggers the corresponding
>  > "check out" with git.
>  
>  > The original tarball will contain (not check out needed )the source
of the
>  > gnu-efi version used for the
>  > corresponding build. But just changing a Makefile variable we would
be able
>  > to build against the different
>  > gnu-efi versions with 0 hassle.
>  >
>  > What do you guys think? Could this be done?
>  
>  Not sure I like the idea of accumulating the versions of gnu-efi.
>  That'd make one submodule per version that has been used at 
> some point in history.
>  And when you work on it and want to just test several of versions of
>  gnu-efi (that are not yet registered as submodule), that'd be annoying
>  to have to patch the makefile and add a new submodule everytime.
>  The submodule repository would have to be cloned from the network, which
>  can be long.
>  
>  For the problem of the tarball sources, we could only perform the
"git
>  submodule update --init" if this is a git repository.
>  
>  Celelibi
>  <<<
> 
> 1) Gnu-efi sources are about 139 KB then I do not think it would be much of
a problem
> having more than one submodule version under the Syslinux building tree.
Also the non-used
> versions could be easily removed when invoking "#make spotless".
> 
> 2) Cloning from the net shouldn't be that bad considering the involved
sizes, plus it is done
> only once for every version.
> 
> 3) Testing versions not registered as submodule yet could be easily done
> w/o touching the makefiles just by i.e. overwriting the content of the last
version submodule
> directory with the sources being tested.
> 
> 4) I think this approach makes very easy testing different gnu-efi
versions; today doing this
> is a real PITA.
> 
> Just my 2 cents.
> 
> Best,
> Patrick
 
With all due respect, I have the feeling we might be putting too much 
effort / resources on the gnu-efi code used in Syslinux. I wouldn't 
even call this "my opinion", but if you would, then please add
"in my
very very very humble opinion".

Although I don't like the fact that we are currently based on an old 
(2014FEB) commit of the gnu-efi code:
 sf.net/p/gnu-efi/code/ci/ab54e2b40e914d0ca01dc3d44c8d4eb8517bf999

and although I also don't like the relative difficulty to change to 
another gnu-efi commit (emphasize on "commit", not
"version"), I would
tend to think that adding / replicating gnu-efi code is not much of a 
gain, while it would take already-limited resources.

I have read posts (here in the Syslinux Mailing List, and elsewhere) 
about this matter, such as not being able to use the gnu-efi code 
already installed on the system, or a different version/commit, or to 
avoid using git and to use some other format (such as a tar archive)... 
If we were to consider such comments / situations, adding an additional 
git repo or additional sub-directories would seem even worse under some 
perspective.

Considering that The Syslinux Project recommends, generally speaking, 
using official binaries, and considering also that reproducing certain 
behaviors would be more difficult if we were to be using different 
bases for the gnu-efi code, perhaps we should not be "easing" the 
possibility of changing such code (i.e. the gnu-efi commit on which 
Syslinux builds upon).

I would like to see, after "6.04-pre1" (whenever it would be 
appropriate and when the changelog deserves it) an update of the 
gnu-efi commit we are based on. Then we could see a "6.04-pre2", so we
can test any potential difference. Alternatively, a separated branch in 
git, updated in parallel to the master branch, with a newer gnu-efi 
commit as base (instead of using the old one from 2014FEB), for tests 
and comparisons, could be perhaps an option.

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

>>>  
 With all due respect, I have the feeling we
 might be putting too much 
 effort /
 resources on the gnu-efi code used in Syslinux. I
 wouldn't 
 even call this "my
 opinion", but if you would, then please add "in my
 
 very very very humble opinion".
 
 Although I don't like the
 fact that we are currently based on an old 
 (2014FEB) commit of the gnu-efi code:
 
 sf.net/p/gnu-efi/code/ci/ab54e2b40e914d0ca01dc3d44c8d4eb8517bf999
 
 and although I also don't
 like the relative difficulty to change to 
 another gnu-efi commit (emphasize on
 "commit", not "version"), I would 
 tend to think that adding / replicating gnu-efi
 code is not much of a 
 gain, while it would
 take already-limited resources.
 
 I have read posts (here in the Syslinux Mailing
 List, and elsewhere) 
 about this matter,
 such as not being able to use the gnu-efi code 
 already installed on the system, or a different
 version/commit, or to 
 avoid using git and
 to use some other format (such as a tar archive)... 
 If we were to consider such comments /
 situations, adding an additional 
 git repo
 or additional sub-directories would seem even worse under
 some 
 perspective.
 
 Considering that The Syslinux Project
 recommends, generally speaking, 
 using
 official binaries, and considering also that reproducing
 certain 
 behaviors would be more difficult
 if we were to be using different 
 bases for
 the gnu-efi code, perhaps we should not be
 "easing" the 
 possibility of
 changing such code (i.e. the gnu-efi commit on which 
 Syslinux builds upon).
 
 I would like to see, after
 "6.04-pre1" (whenever it would be 
 appropriate and when the changelog deserves it)
 an update of the 
 gnu-efi commit we are
 based on. Then we could see a "6.04-pre2", so we
 
 can test any potential difference.
 Alternatively, a separated branch in 
 git,
 updated in parallel to the master branch, with a newer
 gnu-efi 
 commit as base (instead of using
 the old one from 2014FEB), for tests 
 and
 comparisons, could be perhaps an option.
 
 Regards,
 Ady. 
 
 <<<

Please consider in all my previous posts on this topic where I say
"version"
I really mean version, commit, whatever can be retrieved as the whole set of
gnu-efi
sources.

I agree; I think that every official Syslinux version should include
the "oficial" gnu-efi version but developers should be able to change
it easily.
Many times when dealing with Syslinux EFI bugs I considered if the gnu-efi
environment
could've been the culprit but being able to rule that option out takes just
too much time.

Of course people asking for support or reporting bugs should always use the
official Syslinux
sources including the corresponding official gnu-efi version/commit/whatever.

Best,
Patrick

Hi,

On 16/09/2015 21:51, Ady via Syslinux wrote:
 > Considering that The Syslinux Project recommends, generally speaking,
 > using official binaries

Not withstanding this recommendation, shouldn't a source tarball associated
to an _official_release_ (to clarify: 6.04 when it will be ready, not
7.04-pre<n>) contain all that is needed for a regular user to rebuild all
binaries (included the PE/COFF images) using a "standard" toolchain
(with possibly some clearly stated requirements about that toolchain and/or
any other component of the system)?

If a specific component is not included in the tarball, IMO some document
in it should indicate that it is necessary and where to find it.

Or is that not possible for some reason?

Cheers,
Didier

> Hi,
> 
> On 16/09/2015 21:51, Ady via Syslinux wrote:
>  > Considering that The Syslinux Project recommends, generally speaking,
>  > using official binaries
> 
> Not withstanding this recommendation, shouldn't a source tarball
associated
> to an _official_release_ (to clarify: 6.04 when it will be ready, not
> 7.04-pre<n>) contain all that is needed for a regular user to rebuild
all
> binaries (included the PE/COFF images) using a "standard"
toolchain
> (with possibly some clearly stated requirements about that toolchain and/or
> any other component of the system)?
> 
> If a specific component is not included in the tarball, IMO some document
> in it should indicate that it is necessary and where to find it.
> 
> Or is that not possible for some reason?
> 
> Cheers,
> Didier
 
I wish that the required steps to rebuild "anything" in open source 
would be documented appropriately. Reality seems to be different.

The Syslinux Project is certainly _not_ trying to obscure things in 
purpose, but I doubt "just about anyone" can successfully rebuild
every
single component included in Syslinux without some learning curve and 
some experience.

Specifically regarding gnu-efi, I would tend to think that including 
the whole code (matching some commit of the original, or something of 
that sort) in a Syslinux release tarball (or whichever other archive 
format) is not a good idea, for several reasons. So, the alternative - 
according to your email - would be to document how to rebuild the 
gnu-efi submodule used in Syslinux.

At this point, there are three *.sh scripts, and they use either 
another tarball (as Mageia does) or git, pointing to a specific commit 
in the gnu-efi repository. This is not always very comfortable for 
testing / rebuilding, and part of the discussion is about how to 
improve this method.

I don't know whether this answers your question.

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