[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Tentative summary of the amendments



Ian Jackson wrote:
> Jonas Smedegaard writes ("Re: Tentative summary of the amendments"):
> > Quoting Nikolaus Rath (2014-10-22 05:09:18)
> > > I believe Ian's intended reading is that a package that depends on 
> > > uselessd | systemd (but does not work with sysvinit) would be allowed 
> > > by his proposal.
> 
> Yes.
> 
> In practice such packages are not going to be a big problem because
> writing init scripts for them would be straightforward, and then the
> dependency could be relaxed.

So you agree that there is no fundamental problem with packaging
software that requires either systemd or uselessd? Does the GR still
require "someone"(tm) to package uselessd for Debian before packaging
that other (fundamentally OK even by your standards) software is
allowed? To polish uselessd integration until it's actually a usable
init system in Debian? I assume you are not volunteering for this work?

Consider what happens if the uselessd project is abandoned, and systemd
opponents do not come up with any other viable alternative either.
Upstart dies after Canonical abandons it. At some point in the future
developers decide that sysvinit is hopelessly obsolete, and maintaining
support for such an obsolete system will not be help migration to any
new init system appearing in the future (which would likely support at
least basic systemd features anyway). Does this GR imply that such a
decision may not be made without a new GR to override this one? Sysvinit
support must be kept indefinitely just to fulfill the "at least 2 init
systems" requirement?

I think the part about degraded operation with some init systems is
unclear. "Degraded operation with some init systems is tolerable, so
long as the degradation is no worse than what the Debian project would
consider a tolerable (non-RC) bug even if it were affecting all users."
Is this supposed to apply only to init systems that the package
"officially" supports in some sense? If a package works great with
systemd, with tolerable problems with Upstart, and is almost completely
unusable with Sysvinit, then a straightforward reading would suggest
that the GR would make it RC-buggy. Is the idea that the package would
declare that it requires either systemd or Upstart, and as long as there
are at least two such systems, the Sysvinit problems don't count?



Reply to: