On Thu, 08 Aug 2013 18:36:24 +0200 hasufell <hasuf...@gentoo.org> wrote:
> On 08/08/2013 05:23 PM, Tom Wijsman wrote: > > Look into stage3. > Not sure which bits or bytes of stage3 you are referring to; but it coming as default doesn't mean that it advertises it. What's so problematic about replacing something that comes by default? Ignoring defaults, incompatibility doesn't really matter... Should we block stabilization of newer kernels or nvidia-drivers just because they aren't present in stage3, incompatible with each other; I think not. The case for systemd and GNOME 3.8 shouldn't be different... > >> Let me quote myself from another thread: > >> > >>> Maintaining a package in gentoo implies a few things for me: > >>> We are able to support it properly which either means that we can > >>> communicate with upstream or at least (if that fails) fix bugs on > >>> our own. > >> > >> There is nothing "properly" about forcing a particular init system, > > > > That's just your opinion, it depends on how you define "properly"; > > I just defined it. Read my quote again. I did not state you did not define it, your definition is your opinion; in my opinion there's no problem with upstream choosing for systemd. Why should upstream drop progress for supporting a minority anyway? > > not > > all combination of choices are possible, incompatibility with > > packages that can be replaced has never been a reason to not > > maintain a package. If it is a reason that has been agreed on; > > then, please state where. > > I am only talking about stabilization here, maybe that wasn't clear > enough? You've stated that the quote doesn't apply, which is about maintenance. > The virtual is in @system and the default pre-installed implementation > is INCOMPATIBLE with gnome-3.8. Until that is solved (in what way I > don't care), then it should not enter stable arch. Thanks for pointing that out; sounds like something our GNOME team wants to look into, though I wonder if it really is a problem if the upgrade path will just deal with this matter. > On 08/08/2013 05:26 PM, Rich Freeman wrote: > > OpenRC is just one init system that Gentoo supports. Gentoo does > > not require the use of OpenRC any more than it requires the use of > > portage as the package manager. > > So would you stabilize a package that works with paludis, but not with > portage? Ouch. It should probably not be in the tree in the first > place, but I that's not what I have in mind here. This isn't a good example, because the PMS compliance governs over this. > I generally expect packages to work with... now be surprised... BOTH > init systems, although I don't like systemd. If it doesn't work with > one, then it's a bug. Bugs block stabilization. > It is a _REGRESSION_. Ask the arch team about the meaning of > regression if unsure. It's not a regression; actually, it's quite common to drop features that can no longer be supported. I don't see us blocking stabilization for other cases in the Portage tree where a feature has been dropped. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
