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
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
Thanks for letting me ramble anyway.