On Wednesday 16 February 2005 19:53, Dan Armak wrote:
(B> On Wednesday 16 February 2005 09:47, John Mylchreest wrote:
(B> > Morning All,
(B> >
(B> > Further to a previous thread where I said I would get a GLEP ready for
(B> > viewing, please find it here:
(B> > http://dev.gentoo.org/~johnm/files/glep33.txt
(B> >
(B> > All comments or criticisms are more than welcome.
(B> > Please let me know what your thoughts are.
(B>
(B> Quoting GLEP:
(B> > An implication of this (if it wasn't clear from the elib description)
(B> > is that elibs cannot change their exported api dependant on the api (as
(B> > some eclass do for example).
(B>
(B> Sorry, I didn't parse the above... 'dependant on the api', what does that
(B> mean?
(B
(BDitto :)
(B
(B> > The next major release of portage will address this- the environment that
(B> > the ebuild was built in already contains the eclasses functions, as such
(B> > the env can be re-used rather then relying on the eclass. In other
(B> > words, binpkgs and installed ebuilds will no longer go and pull needed
(B> > eclasses from the tree, they'll use the 'saved' version of the eclass
(B> > they were built/merged with.
(B>
(B> How does that work with optional elib imports? Suppose you didn't import it
(B> when merging, and it was later removed from the tree, and you want to
(B> import it when unmerging.
(B
(BWhatever you import during the pkg_setup() phase is what you get through the
(Bentire lifetime of that package instance, including after it's been installed
(Bor made into a binary. I'm not sure what is specified in the GLEP, but the
(Bconditional (= USE-based or arch-based or whatever other data that remains
(Bstatic through the package's lifetime) imports of elibs shouldn't be a
(Bproblem, however eclasses must be unconditional.
(B
(B> Also, I really don't like the idea of removing old-style eclasses from the
(B> tree, and requiring users to manually emerge eclass-compat to be able to
(B> unmerge perfectly valid old ebuilds.
(B>
(B> Firstly, we'll get a _lot_ of queries from users who don't know about
(B> eclass-compat, and they'll be quite upset. IMHO it's an ugly solution.
(B>
(B> Secondly, I don't see why it's needed. You say it's because we can't sign
(B> them easily. But after all eclass devs have moved everything to new
(B> eclasses, we can freeze eclass/* and never ever commit under it again. How
(B> hard would it be, then, to add an eclass/Manifest and sign the whole dir
(B> just once? Wouldn't it look the same as the new signed eclass/elib dirs?
(B
(BWhat's your time-limit on this? 1 year? 5 years? Until death do us part?
(BForever is not really reasonable. The question is just when and how.
(B
(BIDEA #372
(B
(BPortage will be capable of creating an env and saving it with relevant
(Beclasses in-line. Why not create a small tool that converts "old-style"
(Binstdb entries to "new-style" by reading in the ebuild and the appropriate
(Beclasses and creates an appropriate env as would ordinarily be done by
(Bportage.
(B
(BThe eclasses and the tool could then be bundled up and distributed with
(Bportage without portage actually being tied to it. Portage could even detect
(Ban "old-style" env and just spit out a error message and saying how to fix it
(Brather than having to do any special handling.
(B
(BRegards,
(BJason Stubbs
(B
(B--
([email protected] mailing list
