On Wed, Feb 16, 2005 at 08:42:42PM +0900, Jason Stubbs wrote: > > 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. > > > > 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? > > What's your time-limit on this? 1 year? 5 years? Until death do us part? > Forever is not really reasonable. The question is just when and how.
Clarifying a bit on the env misconceptions (seems there are a few), the new release -will- work with older envs (envs generated by older portage installations). So eclass-compat is -only- required for 2 cases- 1) The user hasn't upgraded to a portage version that runs strictly off of the saved env (next major release). After the old eclasses are removed, if they haven't upgraded to said portage version, they can't unmerge. Sucky. Upgrading portage will fix this though (as would merging the eclass-compat ebuild). 2) The installed pkg/binpkg somehow lacks the saved env. This is rare, and usually is related to bad things (TM) happening to the system. Eclass-compat exists -specifically- for this case. The next portage version will be able to ignore missing envs (partially hosed installed pkg entries) -only- for pkg_(pre|post)rm. You wouldn't be able to merge a binpkg that used old eclasses w/out the eclass-compat ebuild being merged though. > IDEA #372 > > Portage will be capable of creating an env and saving it with relevant > eclasses in-line. Why not create a small tool that converts "old-style" > instdb entries to "new-style" by reading in the ebuild and the appropriate > eclasses and creates an appropriate env as would ordinarily be done by > portage. > > The eclasses and the tool could then be bundled up and distributed with > portage without portage actually being tied to it. Portage could even detect > an "old-style" env and just spit out a error message and saying how to fix it > rather than having to do any special handling. Not really needed, as we discussed in irc :) That said, a tool to generate the 'env' of an ebuild (eg, collapse the eclass and ebuild into an env), and have portage use that would be damned useful. It would be a way of snapshot'ing the ebuild's eclass/elibs into it's env, and no longer sensitive to changes in the tree's elibs/eclasses. ~brian -- [email protected] mailing list
