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

[Marius Mauch]

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

> 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  **
> # ***************************************************

Your point being?

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

Which except for the SLOT issues are all fixed as far as I'm concernced.

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

I get see your point here.
`glsa-check -p affected` will shouw you exactly the *minimal* updates
necessary to fix all known vulnerabilities. Not that hard to isolate
the version bumps from the revbumps, is it?
Also your idea has another major problem that renders it more or less
useless:
- you have foo-1.0 installed
- foo-1.0-r1 with major changes is added to the tree
- a security update based on -r1 is added to the tree as foo-1.0-s2
Now what?
a) install -s2 including the changes from -r1
b) add another ebuild -s1 that is foo-1.0 with the security update but
without the -r1 updates

With a) there is no point at all in using the -sX system, with b) you
get into the equality issues (here -r1 and -s1 are not
functionally equal).

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

That's not really what you want.
-s updates might (will) be overlaid with version or revision bumps from
time to time, for this to be of any use it has to happen at the
resolver level (visiblity filter).

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

Everything but the last one is already possible. For the last one you
currently have to read the changelog.

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.