On Wed, Feb 16, 2005 at 12:53:43PM +0200, Dan Armak wrote:
> Quoting GLEP:
> > An implication of this (if it wasn't clear from the elib description)
> > is that elibs cannot change their exported api dependant on the api (as some
> > eclass do for example).
> Sorry, I didn't parse the above... 'dependant on the api', what does that
> mean?
Basically, you can't do
if [[ $SOME_VAR == "blah" ]]; then
func something() { echo "yay"; };
else
func something() { echo "nay"; };
fi
The exported functions from an elib need to be constant- no varying the 'api'
dependant on external vars (which some
current eclasses do).
> > The next major release of portage will address this- the environment that
> > the ebuild was built in already contains the eclasses functions, as such the
> > env can be re-used rather then relying on the eclass. In other words,
> > binpkgs and installed ebuilds will no longer go and pull needed eclasses
> > from the tree, they'll use the 'saved' version of the eclass they were
> > built/merged with.
> How does that work with optional elib imports? Suppose you didn't import it
> when merging, and it was later removed from the tree, and you want to import
> it when unmerging.
Err. Damn, good question, hadn't clarified it- with the next major release of
portage the env will be generated
-once-, during the setup phase. So essentially, you can conditionally pull in
an elib at the global scope (evil), or
w/in pkg_setup (preferable). Pulling in during pkg_setup isn't totally optimal
for binpkgs, but that can be handled
(just have the env 'know' what elibs it has pulled in).
> Also, I really don't like the idea of removing old-style eclasses from the
> tree, and requiring users to manually emerge eclass-compat to be able to
> unmerge perfectly valid old ebuilds.
>
> Firstly, we'll get a _lot_ of queries from users who don't know about
> eclass-compat, and they'll be quite upset. IMHO it's an ugly solution.
Leaving unsigned eclasses sitting in the tree is an equally ugly solution, as
is even allowing for them to be used
after the eclass devs have basically abandoned them. They aren't needed in the
tree after all ebuilds have been
migrated, so why should -all- users have to suffer syncing them? They're
outdated. They're cruft.
Sidenote, the users getting into an uproar over eclass-compat likely are doing
something they shouldn't be. The glep
proposes adding it to the system profiles (I clarified on this in an earlier
email to -dev btw), which means unless
the users have done something -dumb- like --inject'ing the pkg themselves, they
won't even see horkage from it.
New bootstrap'ers/installations after eclass-compat has been added to the tree
won't have the pkg merged, due to
either an injection, or a package.provided. So... where/what will the uproar
be?
> Secondly, I don't see why it's needed. You say it's because we can't sign
> them
> easily. But after all eclass devs have moved everything to new eclasses, we
> can freeze eclass/* and never ever commit under it again. How hard would it
> be, then, to add an eclass/Manifest and sign the whole dir just once?
> Wouldn't it look the same as the new signed eclass/elib dirs?
How hard? Dunno, although I'll state I personally don't care to do it.
Is it worth having two different types of eclass signing methods portage has to
handle?
Not really imo, since the old eclasses are intended to be phased out- why go
and add more cruft to portage then?
That ^^^ is why they should be removed from the tree after the window has
passed.
Beyond that, see my earlier comment for reasons why they should be removed at
some point. The proposed solution is
transfering them to another ebuild after N months, and having that ebuild
required for a certain window (say a year)
via the profiles.
Please explain how modifying portage to do two types of signing, leaving
(potentially dangerous) cruft sitting in the
tree, and having the possibility users/bad devs will use those eclasses is
better then the proposed solution.
Obviously I'm biased, but the proposed solution is cleaner, and addresses the
issues -transparently-. I don't see
what the concern is- the profile solution provides a way to make it completely
transparent to users...
~brian
--
[email protected] mailing list
