Re: [gentoo-portage-dev] Plausible idea for GLEP 19?

[Mikey]

On Saturday 21 January 2006 22:39, Marius Mauch wrote:

> Check the archives for gentoo-dev and gentoo-server, several
> implementation plans have been presented in the not-so-distant past.
> However everyone seems to have a slightly different goal he wants to
> achieve, so maybe the best would be for people to make their goals very
> clear.

I have checked the archives of gentoo-dev, gentoo-server, and have 
researched everything I can find about glep 19.  I have come to the 
conclusion that those "projects" are the /dev/null of gentoo projects.  
Post a request somewhere - "hey, check out glep 19, wink wink".

Let me make my goal clear.  I would like to see some simple features added 
that does not require disruption of current usage, future plans, or require 
massive changes.  I am not interested in reviving dead projects or loft 
goals.

> No point, would rather add a RSYNC_OPTS var finally instead, which gives
> the same functionality (and much more).

If that would work, great.  Not sure how rsync handles ordering/precedence 
of conflicting options, now or in the future.  Also not sure how the 
environment may or may not be manipulated in the future by emerge itself.  
Right now the options are hard-coded into emerge, the simplest place to 
change it in my mind is right there where it happens...

> > 2) Implement a new revision numbering scheme for ebuilds, -sX.  Similar
> > to -rX, but for glsa updates only.  It could be an abbreviation for
> > sticky, security, or stable, whatever you want.
> >
> > For example if I am currently running mysql-4.0.25, the only candidate
> > an emerge -u would consider would be mysql-4.0.25-s1, mysql-4.0.25-s2,
> > etc.... In other words, emerge considers only -sX in its upgrade
> > calculations, instead of -rX, and only considers the same version.
>
> No way. No visible benefit (you know about glep 14 / glsacheck, right?)
> and tons of issues (redundant ebuilds, ordering screwups, ...)

Yes, I am aware of glsacheck.  How long has it been in testing?  Every time 
I try it I get inconsistent results.  Something about "WARNING: This tool 
is completely new and not very tested, so it should not be
used on production systems. " kind of makes me hesitate to use it.

As far as redundant ebuilds and ordering screwups.  If you change line 3173 
of portage.py to:

	if len(myrev) and myrev[0] in ["r","s"]:

Everything works quite well actually.  The s is sorted after the r, so -s7 
would install after -r6 or instead of -r7.  It is actually a much simpler 
solution than glsa, could be introduced immediately to the portage tree, 
and use of it could be optional.  People could use them in their own 
overlays, backport their own security fixes.

> No chance you get people to agree on something that will bloat the tree
> without any real benefit. Mind that we already revbump packages for
> security updates.

Packages are not only revbumped for security updates.  I have not researched 
it much, but I would be willing to be the vast majority of revbumps are 
_rarely_ for security updates.  Most of the time glsas suggest to bump up 
to the next version of the package, not revision...  There is also no way 
to distinguish between a revbump that alters the package via a revbump that 
is only because a glibc has just been marked stable for another 
architecture, for example.

> No, this includes way too many changes to core functions (version
> comparison, resolver) with no visible benefit (from my POV). In case you
> haven't done so already take a good look at glep 14 and glsa-check
> (which implements the least-invasive update algorithm you seem to be
> after).

I am happy to see that you state that the "no visible benefit" is limited to 
your POV.  Glep 14 (glsa-check) is a fine idea, a fine proposal.  The only 
problem is that it appears as though it is never going to happen, at least 
not the final goal - to get integrated into portage.

I like my idea better.  It is a very simple change that could be introduced 
immediately with little or no ill effect.  Functionally, that one line 
patch I posted above would work as far as I can tell.  It instantly creates 
a framework for backporting security fixes (without affecting current 
usage), glsa does not.  GLSA updates would then become a fairly simple 
matter - emerge -Du world, filter out all non -sX packages.  Extend the 
idea further and people who desire could filter syncs to just retrieve 
*-sX.ebuild and your load on the mirrors has just lightened, not grown..