Re: [gentoo-dev] RFC: GLEP 19 -- Gentoo Stable Portage Tree

[Dan Armak]

On Tuesday 03 February 2004 18:05, Kurt Lieber wrote:
> On Tue, Feb 03, 2004 at 05:06:01PM +0200 or thereabouts, Dan Armak wrote:
> > A bigger inconvinience is that every developer will have to maintain a
> > stable tree system image (or real system) to test any off-cycle updates
> > he may have to do, often hurrying because of a major vulnerability
> > already published. will that be required? Is there a way around it?
>
> There should be *very* few cases where this happens.  For the most part,
> devs will only be committing things off-cycle to the stable tree that are
> already in the main tree.  For example: Another half-dozen exploits are
> found in gaim.  The gaim herd/maintainer fixes up the new ebuild and
> commits it first to the main tree (generally ~masked) and then to the
> stable tree (probably as ~stable).
>
> The only time where I can see a problem is when there is an ebuild still in
> the stable tree that no longer exists in the main tree.  However, by then,
> I would hope all major/critical bugs have been worked out of it, so only
> security issues would be a problem.

I meant a scenario like this:
- foo-1 and mylib-1 are in the stable tree.
- Time passes and mylib-2 and foo-2 enter the main tree.
- One day exploits are found in foo; foo-2-r1 which contains the fixes is 
added to the stable tree. It only depends on >=mylib-1, so mylib-2 isn't 
added to the stable tree.
- The combination foo-2 + mylib-1 is buggy. But no-one ever tested it, because 
foo-2 came out after mylib-2 and that's what everone tested it with. So the 
bug will make its first appearence in the stable tree.

This is an unlikely event but with a big enough tree with lots of 
interdependencies it will happen occasionally. Similar things happen 
sometimes in the main tree, and we have to change a dep to require the latest 
version of a library, not because the library's new functionality or 
interface is required, but because the new app version triggers bugs in the 
old library version.

(I'm reminded of the libxml2/libxslt vs. kde docs versioning story, though 
that was somewhat different...)

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951