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

[Mikey]

Marius Mauch wrote:

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

Users are discouraged from changing make.globals.  It would be better to
implement in make.conf or as a command line option to emerge itself.  It is
a configuration item for a user preference, not a (global) portage
preference...
 
>
> Which except for the SLOT issues are all fixed as far as I'm concernced.
>

That is not a small issue.

> 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

If major changes are introduced, it _should be foo-1.0 -> foo-1.1, not
foo-1.0 -> foo-1.0-r1.  As far as I know, the -r is for minor packaging
relating revisions specific to gentoo, not upgrades to the underlying
package itself.  But relying on that is living in a dream world, so that
does pretty much make my idea useless.  You would have to attempt to do
something along the lines of -r1-s1, which would require a ridiculous
amount of ugly hacking.  In spite of that, I am still not convinced it is a
bad idea...

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

"Normal" emerges would take -s2 over -r1 or -s1.  The change is transparent
when not in "glsa-only" mode.

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

It does not allow for backporting, it is not safe to use in an automated
environment, it does not work in a production environment, and it does not
scale well.


-- 
gentoo-portage-dev@g.o mailing list