On Thu, Aug 8, 2013 at 9:47 PM, Tom Wijsman <tom...@gentoo.org> wrote: > On Thu, 8 Aug 2013, 20:57:18 +0300 > Alon Bar-Lev <alo...@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 <alo...@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...
This is called a 'profile'. You can have systemd and openrc profiles, and then able to mask specific packages... It is a technical solution, but won't make lives much easier in this regard. Regards, Alon Bar-Lev
