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 :)