Zac Medico <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 04 Nov 2006 04:08:24 -0800:
> Petteri Räty wrote: >> Zac Medico kirjoitti: >>> The sooner that we start storing eclasses.tbz2 for each installed >>> package, the sooner that we will be able to have more freedom with the >>> eclasses in the live portage tree. >> >> One thing that comes to mind is that how do we handle the case where >> the old version of the eclass has a major bug in pkg_postrm for >> example. > > I suppose we could check the live tree for the required eclasses and use > them if they are all available. Perhaps, in that case, we should use > the live ebuild too if it is available. In cases where something isn't > available in the live tree we could fall back to the saved files as a > last resort. We'd have to maintain api compatibility, but at least > there would still be a reasonable chance for the user to do a normal > uninstall after some eclasses have been removed. What about some way of marking priority, along with versioning of some sort? Default to using the stored versions unless there's something in-tree that says it's higher priority for version X. Ideally, the need for out-ranking the stored version wouldn't come along that often, and the checked policies could be centralized in a file in base-profile or the like for speed, preferably with comments indicating the dates the bad version was "live", and an expiry, say 30 days after bump of all affected packages for unstable, 180 days after bump of affected packages for stable. I'm thinking something along the lines of package.mask, but probably not cascaded, only in the base profile. Note that this would /only/ contain the supersede /policies/, including a pointer to the appropriate ebuild/eclass/elib/whatever. The idea being to keep the incremental data portage has to parse down to a minimum -- one file -- unless it mentions an ebuild/eclass/elib (when/if they are implemented) used by the package being removed. (It'd actually have to be one file per repository, where multiple repositories are supported and used, of course.) Only if something of interest were mentioned in the central file would the tree version of the e-whatever file need to be parsed, thus keeping speed up and complications from parsing some stuff from the live tree and some from the saved files to a minimum, using the saved files, and thus the environment as it was at the time of install, by default. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [email protected] mailing list
