On Sunday 22 January 2006 16:56, Marius Mauch wrote:

> > > 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.
>
> You didn't understand what I said. If you just play around with the
> output info you'll miss updates.

How will I miss updates?  "Standard" actions (system world) or myfiles would 
work the exact same as they do now, they just consider a new revbump 
specifier in the digraph calculation.

The "non-standard" action that I am proposing, call it "emerge glsa-only", 
would take the output from emerge -Du world and filter out anything from 
the resulting package list except for -s packages.  I will only "miss" 
updates that are not strictly security related.  If there is no 
security-only related update, i.e. I have to upgrade to the next version, 
glsa-check will report it and I will have to manually update.  

I have attached rough proof of concept patches, the only thing missing is 
the version matching check.  I still have to figure out the best way to 
compare the currently installed version -vs- the update version...

> Sorry? What prevents anyone from doing backports? It's as safe as your
> idea for both automatic and manual (unless you assume that all security
> updates will only ever be a -sX bump), and the last two are just random
> comments that don't mean anything.

Bad choice of words.  Neither method prevents anyone from doing backports, 
but one method allows you to continue _only_ installing backports (if 
available) instead of version bumps.

For example, for some bizarro reason, I have a requirement to continue 
running mysql-4.0.25.  A glsa is published, requiring an upgrade to 
mysql-4.1.x.  The mysql ebuild maintainer no longer maintains the 4.0.25 
tree, but debian has a patch that fix the vulnerability.  For users in my 
situation, a new ebuild can be created (mysql-4.0.25-s3) with the new 
patch, I can continue on safely using my required version of mysql.  Users 
without such stability requirements can just emerge -u and get the latest 
stable version of mysql for their arch.  Everybody is happy?

> Anyway, showed you why it won't work and why it won't get implemented,
> so rather pointless to continue this.

The only show stoppers you mentioned is the installation of s5 with all of 
r4's updates that were not desired and the older emerges choking on weird 
names.  

The first problem could be worked around by having the "normal" actions 
(system, world, myfiles) not consider the new s extension in depgraph 
calculations.  Even without this workaround, it still might be a worthy 
feature.  I don't know about the 2nd problem, I would have to test to see 
what happens...

Thanks for letting me ramble anyway.