On Sunday 22 January 2006 13:02, Marius Mauch wrote: > Well, posting YAIP (yet another implementation plan) won't really help > either.
Correct, plans never seem to go anywhere in regards to this... > Don't see the goal here, just the constraints. Are you after a > non-moving tree, a tree with just security fixes, visibility filters in > portage, a new `emerge moo` graphics, ... ? The existing tree with additional functionality. Implemented via a new revision type. > > > No point, would rather add a RSYNC_OPTS var finally instead, which > > > gives the same functionality (and much more). > Yeah, RSYNC_OPTIONS would remove all that hardcoded stuff and put it in > make.globals instead. From make.globals: # ***************************** # ** DO NOT EDIT THIS FILE ** # *************************************************** # **** CHANGES TO make.conf *OVERRIDE* THIS FILE **** # *************************************************** # ** Incremental Variables Accumulate Across Files ** # ** USE, CONFIG_*, and FEATURES are incremental ** # *************************************************** > I removed the warning in gentoolkit-2.1 (wanted to do that for quite > some, just didn't get around to do it). What kind of inconsistent > results are you speaking of? http://www.gentoo.org/proj/en/portage/glsa-integration.xml, section on known problems. The plan is nice. It does not, however, address the needs of some users to have a STABLE system as well. Some users can't willy nilly upgrade to the next version of a package because they might have requirements to stay at the same version. Through something as simple as adding a new revision specifier, a framework can be in place to backport security fixes or ONLY apply revisions that are security related... > Still has issues as this allows for multiple equal versions to exist > (as -rX == -sX). And no, it could not be used immideately in the tree In this case the s is seen as more recent (I have already tested it). If there is a -r5 and a -s5 package, the -s5 package is seen as the most recent. The depgraph must be sorting alphabetically. You could, in effect, migrate towards having revbumps that only add security fixes as -s. Revbumps that are trivial (becoming stable in another arch) could continue being -r. Either way, if they were exact copies of the same ebuild, no harm, no foul. > as unaware portage versions would fail with interesting errors (see > glep 45 for background info), same reason the versioning extensions in > 2.1 can't be used yet (even if 2.1 would be stable). And I'm quite sure > that if this would be used in the tree we'd hit versioning screwups > sooner or later (-sX -> -rX+1 -> -rX+2 -> -sX+1). Damn you, damn you all to hell! > I didn't claim that all/the majority of revbumps are security related. > And there is a way to distinguish the different kind of revbumps: read > the changelog. Hah hah, funny. > Well, it "only" needs a way to feed a set of nodes into the dep > resolver. But that in turn is quite a task as the dep resolver code is > nasty. I have looked at the dep resolver and don't want to go near it with a 10 foot pole. I only want to do the functional equivalent of filtering out anything but "*-sX$" (pseudo regex) during the final doemerge or when displaying in case of --pretend. > What functionality does it actually add? The changes you described so > far just allow multiple letters as revision prefixes. The main thing of > your proposal was probably to limit updates to -s updates, and that's a > tricky goal. It enables ebuild maintainers to backport security patches. It allows them to fix security problems that are not glsa alerts. It does not require the use of a new tool or integration of glsa into portage. It allows users to distinguish between revbumps of a trivial nature and revbumps of a security nature. > Wow, allowing multiple letters for revision prefixes counts as creating > a framework theses days ;) Yes, I believe it can. The same way -r is a framework for updating existing packages. > Again, you haven't touched the resolver yet, so you're not filtering > anything out so far. And that is the crucial part here as far as I > understand your proposal. Working on it... What a nightmare. I don't want to touch the resolver code, only call a different altlist to pass to mydepgraph.merge() or mydepgraph.display() that filters out anything but -sX packages. I am also learning python as I go. Something along the lines of: emerge glsa-updates (new action) internally do an emerge -Du world to get the depgraph filter final call to act only on -sX packages Like you said, that appears to be the not-quite-so-simple part of my master plan :)
pgp07rM7AJLqd.pgp
Description: PGP signature
