Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations? (was: Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8)

[Tom Wijsman <TomWij@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2235 bytes --]

On Thu, 8 Aug 2013, 20:57:18 +0300
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> If from now on, a bug with systemd of new version of a package blocks
> that package stabilization, it means that all developers must support
> systemd. So having systemd stable is a decision that should be made by
> the entire community, and have huge overhead on us all.  

On Thu, 8 Aug 2013 21:23:29 +0300
Alon Bar-Lev <alonbl@gentoo.org> wrote:

> selinux - if a package breaks selinux it will be reverted (if
> maintainer care about his users) until resolution is found.
> 
> as you may have unusable system if a bump does not support specific
> stable init layout, you do expect rollback similar to libselinux
> issue. init layout is not optional package nor optional feature, it
> how the system operates.

Reverting and rolling back isn't really the good way going forward, it
implies waiting and that's going to certainly make people sad because
they need to wait for something that doesn't affect the package
combination that the user uses; we need to look at a different approach.

What if we could stabilize package combinations instead of packages? Or
rather, when during stabilization it was found that a certain package
combination doesn't work, exclude that combination from stabilization?

This is a concept that shouldn't be too hard to implement; it could
even be implemented using existing USE flag mask opportunities, although
we probably would have to figure out a solution for those occasions
where an USE flag is not present.

Perhaps specify in the ebuild that the package shouldn't be regarded as
keyworded for a certain dependency?

Since it's just an idea that jumps to mind, I'm not sure if this is the
best approach to do this; but we'll probably want to start brainstorming
in this field if this is going to stay or become a big problem.

Multiple implementations shouldn't block Gentoo going forward.

We need to come up with a solution similar to the above to avoid this...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]