On Monday 23 January 2006 04:56, Patrick Börjesson spammed:

> The problem with your reasoning is that portage only reports the
> "highest" upgrade (from it's point of view). So if you have package
> A-1.0 installed and two possible upgrades, say A-1.0-s1 and A-1.1, then
> portage will chose the "highest" of the two. So the output from that
>
> command would be:
> | These are the packages that I would merge, in reverse order:
> |
> | Calculating world dependencies ...done!
> | [ebuild     U ] the-cat/A-1.1 [1.0] ......
>
> It will not output the following:
> | These are the packages that I would merge, in reverse order:
> |
> | Calculating world dependencies ...done!
> | [ebuild     U ] the-cat/A-1.0-s1 [1.0] ......
>
> So you _will_ miss upgrades if you only filter the output of emerge in
> your solution and expect to get all security related upgrades relating
> to the package you're using.

That is _exactly_ how it is intended to work.  "Normal" users will get A-1.1 
when they run emerge -u.  Users with a need for stability will only see 
A-1.0-s1, and only if it is available for A-1.0.

Perhaps I should have named it "hotfix" instead of "glsa-only".  This 
feature is targeted towards environments that prioritize stability slightly 
over security.  Often it is not an option to upgrade to the next version of 
something until it has been regression tested, various apps have been 
migrated/ported, etc...

My patches alone don't make this possible, but they at least provide a 
framework for it to happen in the future.  Users who need backported 
security fixes could band together for the major apps and do the work, the 
-s packages could be distributed via overlays (so as not to interfere with 
old versions of portage).