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

[Marius Mauch]

On Sun, 22 Jan 2006 10:25:37 -0600
Mikey <mikey@×××××××××××.com> wrote:

> 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".

Well, posting YAIP (yet another implementation plan) won't really help
either.

> 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.

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, ... ?

> > 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...

Yeah, RSYNC_OPTIONS would remove all that hardcoded stuff and put it in
make.globals instead.

> > > 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.

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?

> 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.

Ok, so you just want to have another letter that does exactly the same
as -rX, just with a semantic difference.
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
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).

> > 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.

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.

> > 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.

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 like my idea better.  It is a very simple change that could be
> introduced immediately with little or no ill effect.

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.

> 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.

Wow, allowing multiple letters for revision prefixes counts as creating
a framework theses days ;)
Sorry, but that change doesn't really do anything.

> 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..

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.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.