Bug#727708: init system coupling etc.
On Thu, Feb 13, 2014 at 06:01:56PM +0000, Ian Jackson wrote:
> I suppose what I mean is that a problem which occurs due to "wrong"
> init system is a real problem and should not be reduced in severity or
> excused on the grounds that the particular init system is defined as
> "required" (whether via a dependency or otherwise).
>
> So if the degraded operation amounts to a missing feature (a bug of
> wishlist severity), then that's a bug of wishlist severity (and might
> be closed or tagged "wontfix").
>
> If the degraded operation amounts to a plain bug (ie bug of normal
> severity), then that's a bug of normal severity. Packages with bugs,
> even regressions, are of course routinely uploaded and released.
> Whether to do so is a tradeoff which we leave the maintainer to
> consider.
If you consider a dependancy as a bug... then the next question might have to
be - who's is the bug. Is it the fault of the package or group of packages
such as GNOME needing a feature/api - or is it the fault of alternative
feature providers that they do not provide the facilities required - ie
the fault of the init system.
Is innovation and progress a bug?
Or is stagnation a bug?
Surely the "bug" is with packages that do not provide what is needed (yet).
So in this case I would feel then that it could be considered a bug that OpenRC,
Upstart etc do not provide (yet) the features that GNOME need/want to depend
on. But there is hope for technical solutions to be found for those problems
as they arise - as systemd-shim shows. (Personally I think that package has an
exceedingly misleading name! Am I alone?)
> If the degraded operation amounts to a bug of RC severity, then that's
> a bug of RC severity and the new version of the requiring package
> should be blocked from transitioning to testing, or being released,
> until the problem is fixed, or at least worked around so that it is no
> longer RC.
So we should start raising bugs against sysvinit,openrc,upstart etc for any
features that systemd has that might be useful, but which are missing in
those respective packages?
There being more than one way to see this problem, I hope we can go the way
Keith has proposed: Now that the issue is clearly in focus for project
maintainers I would be very surprised if amicable technical resolutions
cannot be found as they are required.
IMHO the big issue for the project really was/is which is the default init
system for Jessie which for Jessie, and against which all packages must
fully work. Potential GR aside, happily the work to focus on that target
can now commence in earnest.
Regards
Reply to: