1 |
On Monday 23 January 2006 04:56, Patrick Börjesson spammed: |
2 |
|
3 |
> The problem with your reasoning is that portage only reports the |
4 |
> "highest" upgrade (from it's point of view). So if you have package |
5 |
> A-1.0 installed and two possible upgrades, say A-1.0-s1 and A-1.1, then |
6 |
> portage will chose the "highest" of the two. So the output from that |
7 |
> |
8 |
> command would be: |
9 |
> | These are the packages that I would merge, in reverse order: |
10 |
> | |
11 |
> | Calculating world dependencies ...done! |
12 |
> | [ebuild U ] the-cat/A-1.1 [1.0] ...... |
13 |
> |
14 |
> It will not output the following: |
15 |
> | These are the packages that I would merge, in reverse order: |
16 |
> | |
17 |
> | Calculating world dependencies ...done! |
18 |
> | [ebuild U ] the-cat/A-1.0-s1 [1.0] ...... |
19 |
> |
20 |
> So you _will_ miss upgrades if you only filter the output of emerge in |
21 |
> your solution and expect to get all security related upgrades relating |
22 |
> to the package you're using. |
23 |
|
24 |
That is _exactly_ how it is intended to work. "Normal" users will get A-1.1 |
25 |
when they run emerge -u. Users with a need for stability will only see |
26 |
A-1.0-s1, and only if it is available for A-1.0. |
27 |
|
28 |
Perhaps I should have named it "hotfix" instead of "glsa-only". This |
29 |
feature is targeted towards environments that prioritize stability slightly |
30 |
over security. Often it is not an option to upgrade to the next version of |
31 |
something until it has been regression tested, various apps have been |
32 |
migrated/ported, etc... |
33 |
|
34 |
My patches alone don't make this possible, but they at least provide a |
35 |
framework for it to happen in the future. Users who need backported |
36 |
security fixes could band together for the major apps and do the work, the |
37 |
-s packages could be distributed via overlays (so as not to interfere with |
38 |
old versions of portage). |