| 1 |
On Sunday 22 January 2006 16:56, Marius Mauch wrote: |
| 2 |
|
| 3 |
> > > That's not really what you want. |
| 4 |
> > > -s updates might (will) be overlaid with version or revision bumps |
| 5 |
> > > from time to time, for this to be of any use it has to happen at the |
| 6 |
> > > resolver level (visiblity filter). |
| 7 |
> > |
| 8 |
> > "Normal" emerges would take -s2 over -r1 or -s1. The change is |
| 9 |
> > transparent when not in "glsa-only" mode. |
| 10 |
> |
| 11 |
> You didn't understand what I said. If you just play around with the |
| 12 |
> output info you'll miss updates. |
| 13 |
|
| 14 |
How will I miss updates? "Standard" actions (system world) or myfiles would |
| 15 |
work the exact same as they do now, they just consider a new revbump |
| 16 |
specifier in the digraph calculation. |
| 17 |
|
| 18 |
The "non-standard" action that I am proposing, call it "emerge glsa-only", |
| 19 |
would take the output from emerge -Du world and filter out anything from |
| 20 |
the resulting package list except for -s packages. I will only "miss" |
| 21 |
updates that are not strictly security related. If there is no |
| 22 |
security-only related update, i.e. I have to upgrade to the next version, |
| 23 |
glsa-check will report it and I will have to manually update. |
| 24 |
|
| 25 |
I have attached rough proof of concept patches, the only thing missing is |
| 26 |
the version matching check. I still have to figure out the best way to |
| 27 |
compare the currently installed version -vs- the update version... |
| 28 |
|
| 29 |
> Sorry? What prevents anyone from doing backports? It's as safe as your |
| 30 |
> idea for both automatic and manual (unless you assume that all security |
| 31 |
> updates will only ever be a -sX bump), and the last two are just random |
| 32 |
> comments that don't mean anything. |
| 33 |
|
| 34 |
Bad choice of words. Neither method prevents anyone from doing backports, |
| 35 |
but one method allows you to continue _only_ installing backports (if |
| 36 |
available) instead of version bumps. |
| 37 |
|
| 38 |
For example, for some bizarro reason, I have a requirement to continue |
| 39 |
running mysql-4.0.25. A glsa is published, requiring an upgrade to |
| 40 |
mysql-4.1.x. The mysql ebuild maintainer no longer maintains the 4.0.25 |
| 41 |
tree, but debian has a patch that fix the vulnerability. For users in my |
| 42 |
situation, a new ebuild can be created (mysql-4.0.25-s3) with the new |
| 43 |
patch, I can continue on safely using my required version of mysql. Users |
| 44 |
without such stability requirements can just emerge -u and get the latest |
| 45 |
stable version of mysql for their arch. Everybody is happy? |
| 46 |
|
| 47 |
> Anyway, showed you why it won't work and why it won't get implemented, |
| 48 |
> so rather pointless to continue this. |
| 49 |
|
| 50 |
The only show stoppers you mentioned is the installation of s5 with all of |
| 51 |
r4's updates that were not desired and the older emerges choking on weird |
| 52 |
names. |
| 53 |
|
| 54 |
The first problem could be worked around by having the "normal" actions |
| 55 |
(system, world, myfiles) not consider the new s extension in depgraph |
| 56 |
calculations. Even without this workaround, it still might be a worthy |
| 57 |
feature. I don't know about the 2nd problem, I would have to test to see |
| 58 |
what happens... |
| 59 |
|
| 60 |
Thanks for letting me ramble anyway. |
Archives