Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Josh Triplett]

On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> The loader is still available via the old path, so external/third
> party/local/other software works unchanged. This should negatively
> only affect our 1st party packages, when running on a non-merged
> distro.
> And are _all_ our packages really 100% compatible with other distros
> at all? Are they even supposed to be?

People build things on Debian that are not Debian packages. People
compile binaries on Debian, and expect them to work on any system that
has sufficiently new libraries.

This is *not* about Debian packages failing to work on other
distributions; this is about *software compiled on Debian* faliing to
work in other environments.

If you build a dynamically linked binary that only depends on glibc, you
can expect it to be reasonably portable, to any system that uses glibc
and has a sufficiently new version.

Debian stable is, in fact, one of the common environments people use to
compile binaries for distribution.

> So, what I am asking is, what actual, real difference does it make if,
> by default (and with an override available for example), packages
> built on Debian for Debian record the ld path to point to its (actual)
> location on Debian, via say a compiler spec file that is injected in a
> deb build?

Making binaries built *on* Debian different than binaries built *for*
Debian would introduce a needless additional source of complexity,
compared to just compiling code the same way in both cases.

To frame this in different terms: consider that one of the major goals
of systemd has been to harmonize across distributions and eliminate
needless variations that don't serve much actual purpose (e.g.
variations in config file paths for the same config file). Consider how
much effort systemd went to work with distributions, understand and deal
with the *important* variations, and try to convince them to abandon the
*unimportant* variations. Now imagine if someone came along and said
"let's patch systemd to put unit files in /purple/; it'll work with
everything in our distribution".

Or, imagine if someone said "let's inject an argument to gzip, only for
building the .gz files sihpped in our packages of course, to modify the
gzip header and remove a few of the extraneous additional fields; it'll
be fine, because we've patched our gzip to parse it"

The x86-64 ABI is set. Feel free to make the case to the next
architecture designer that their new ABI should have the dynamic linker
in `/usr/lib`. That would *not* have the same downsides, as long as
everyone agrees on a path.

- Josh Triplett

Re: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[Josh Triplett]

Sam Hartman wrote:
> that looks like you are proposing doing it in an expedited manner *as
> part of usrmerge*

I am not proposing doing *anything* in an expedited manner. I don't
think it'd be feasible to make such a change in an expedited manner even
if we *wanted* to, and in any case I wouldn't expect that. And I'm
certainly not proposing making a change "as part of usrmerge".

(I realize the subject of this message is about merged /usr. However, the
point of this was not "let's change it because merged /usr"; the point
was "perhaps we should take a look at this and evaluate it".)

I was attempting to look at the system as a system, ask a question that
I've seen raised many past times, and ask if there may be value in
*having a discussion about it*. I would expect such a discussion to
happen in parallel, and any potential change that arose as a result of
it to happen in parallel, uncoupled to anything else.

It seems unfortunate when *bringing up* the possibility of *discussing*
a change is viewed as breaking things. I suggested "evaluating the net
value" of /etc/shells. Part of the point of such an evaluation would be
to discover, in fact, how people use it, what value it provides, what
people's use cases are, what detriments it has, what other ways the same
problems could be solved, and similar. That, to me, seems like precisely
the kind of process by which people's input *can* be heard and
respected.

I don't think there are any areas of functionality that we shouldn't
*evaluate* and consider possibilities in. That doesn't mean we should
ever gratuitously change things without discussion and without taking
input and use cases into account.

- Josh Triplett

Re: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[Josh Triplett]

Johannes Schauer Marin Rodrigues wrote:
> I just remembered a pending MR that I'd say is a little more important than
> "good to have":
> 
> https://salsa.debian.org/debian/debianutils/-/merge_requests/21
> 
> Without this one-line change, /etc/shells on merged-/usr systems will have 
> some
> shells listed twice and some shells (like /usr/bin/bash) missing. The reason
> is, that dpkg-realpath doesn't support merged-/usr and thus a workaround is
> needed.

Over the years, I've seen a few proposals floated to consider dropping
/etc/shells; this would just require dropping pam_shells.so from
/etc/pam.d/chsh. That would also have the side effect of solving this
problem, and making one less thing requiring maintainer scripts.

Would it be worth reopening that discussion, and evaluating the net
value of continuing to maintain /etc/shells?

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On April 8, 2022 6:31:27 AM PDT, Wookey  wrote:
>If they want to prove that no patches for the current approach will
>ever be accepted, that can only be done by engaging further. Yes it
>will be hard work, but if it's not done we are just stuck. 

It sounds like at least one patch has already been rejected, not with comments 
about the patch needing work (which it absolutely does), but AIUI with 
"usrmerge is broken by design". That seems like sufficient proof that the 
problem is not a lack of engagement or patches. I don't think it's reasonable 
to expect further one-sided engagement by way of further "proof" of futility. 
That's leaving aside the (likely also accurate) expectation based on reported 
experiences with multiarch that any patch will go through extreme amounts of 
rework and iteration in that hostile environment, even *if* there were enough 
trust left to expect good faith.

I would love to see some engagement from the dpkg side, beyond reverting NMUs 
and subverting project decisions. Literally a single sentence would largely 
solve this: "as much as I disagree with this decision, I will stop shipping or 
recommending dpkg-fsys-usrunmess, and I will merge a reasonable patch to 
support usrmerge via directory symlinks in dpkg".

In the absence of such engagement, it would help if the TC provided the 
equivalent of both halves of that statement. But in either case, I think it's 
reasonable to not expect people to enthusiastically participate in a hostile 
and gruelling development environment in dpkg in the wake of a TC override 
(whether the one mentioned here or the one that has already taken place).

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, Mar 24, 2022 at 11:56:02PM -0700, Josh Triplett wrote:
> On Tue, Mar 15, 2022 at 03:14:37PM -0700, Josh Triplett wrote:
> > It would appear that the situation has deteriorated further. dpkg 1.21.2
> > now issues a warning on all merged-usr systems:
> > 
> > Setting up dpkg (1.21.2) ...
> > dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
> > dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.
> 
> Update: in dpkg 1.21.3, the warning now reads:
> 
> dpkg: warning: This system uses merged-usr-via-aliased-dirs, going behind 
> dpkg's
> dpkg: warning: back, breaking its core assumptions. This can cause silent file
> dpkg: warning: overwrites and disappearances, and its general tools 
> misbehavior.
> dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.
> 
> While more explicit, I think the issue remains, both with this message
> and with the page it links to.

Update: we're now even further into full-blown "fights in the archive"
territory:

https://lists.debian.org/debian-devel-changes/2022/03/msg03658.html
Changed-By: Bastian Blank 
Changes:
 dpkg (1.21.5+nmu1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Revert rebellion against CTTE decision #994388:
 - Remove warning about unsupported system.
 - Don't install dpkg-fsys-usrunmess.

https://lists.debian.org/debian-devel-changes/2022/03/msg03660.html
Changed-By: Guillem Jover 
Changes:
 dpkg (1.21.6) unstable; urgency=medium
 .
   - This also clears a bullying NMU. -
 .
   [ Guillem Jover ]
   * Documentation:
 - man: Document untracked kernel module files handling in
   dpkg-fsys-usrunmess(8).

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Fri, 25 Mar 2022 11:05:26 -0600 Gunnar Wolf  wrote:
> However, even given his attitude, I trust he would apply a correctly
> done patch addressing the issue at hand.

I just read the dpkg git commit
(57e084a52e1ede33b7914c3e0357311ac370a186) that added this warning in
the first place. Quoting the commit message:

> debian: Warn in postinst about merged-/usr-via-aliased-dirs breakage
>
> dpkg does not, and has never supported this filesystem layout even less
> so the way it has been deployed as it bypasses dpkg entirely. It can
> cause file loss, file overwrites, unexpected query results, among other
> things, while being very insidious to detect if one is not aware. Adding
> support for it would be rather infeasible and gets in the way of features
> that have been on the works for some time now.

The last sentence ("Adding support for it would be rather infeasible and
gets in the way of features that have been on the works for some time
now.") would seem to be an objection to adding such support even given a
patch.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Tue, Mar 15, 2022 at 03:14:37PM -0700, Josh Triplett wrote:
> It would appear that the situation has deteriorated further. dpkg 1.21.2
> now issues a warning on all merged-usr systems:
> 
> Setting up dpkg (1.21.2) ...
> dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
> dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.

Update: in dpkg 1.21.3, the warning now reads:

dpkg: warning: This system uses merged-usr-via-aliased-dirs, going behind dpkg's
dpkg: warning: back, breaking its core assumptions. This can cause silent file
dpkg: warning: overwrites and disappearances, and its general tools misbehavior.
dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.

While more explicit, I think the issue remains, both with this message
and with the page it links to.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, 24 Mar 2022 19:24:02 -0700 Sean Whitton  
wrote:
> This is how I see it as well.  Putting aside the postinst warning, the I
> can't see anything the TC could do beyond what we've already done, until
> there's a patch on the table.

I'm glad to hear that the postinst warning is something that could be
addressed regardless.

But also, given that the postinst warning occurred after the previous TC
ruling, I don't think the previous TC ruling alone gives sufficient
confidence that a patch would not be ignored or rejected. I don't think
anyone is expecting the TC to pre-approve a patch sight-unseen; rather,
in the past the TC has used wordings like "merging reasonable
contributions" to give some indication of what the TC expects.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, 24 Mar 2022 16:22:38 -0700 Russ Allbery  wrote:
> Luca Boccassi  writes:
> 
> > If it was possible to do it, it would have already happened, and we
> > wouldn't be discussing it at all, it would have just been done.
> 
> Has someone written a patch against dpkg that causes it to do the right
> thing?
> 
> > In the end, at the very least this is a _workable_ proposal. It might
> > not be ideal, but we know it can work. What's your counter-proposal?
> 
> Someone who believes strongly in merged-/usr should write a patch against
> dpkg that causes it to work properly with merged-/usr, including edge
> cases like files moving out of /bin and /lib between packages and dpkg -S
> working properly.
> 
> I understand that you don't think that patch will be accepted.  But we
> don't actually know that since so far as I know it doesn't exist.  We're
> arguing in the abstract about a future problem that hasn't happened yet
> because we don't have working code to argue about.

I think it's appropriate for people to wait on such work until there's
guidance from the TC ensuring that such a patch will be accepted.
Otherwise, anyone spending time writing it is spending substantial
effort that may well be wasted.

I am also hoping that such a patch is not a precondition for removing
the message from the current dpkg maintainer script, which is already
causing issues.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, Mar 24, 2022 at 01:24:39PM -0700, Russ Allbery wrote:
> Josh Triplett  writes:
> > On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery  wrote:
> 
> >> That said, I personally am disappointed that the folks who have been
> >> pushing merged-/usr forward are willing to leave dpkg in a known-buggy
> >> state without attempting to patch it to fix the remaining issues.  I
> >> realize that there are various obstacles in successfully doing that,
> >> not all of which are technical,
> 
> > I don't think "willing to" is a fair characterization here.
> 
> It's possible that you haven't seen the discussions that I've been in, but
> whenever I point out that this hasn't been fixed and that we should fix
> it, I am told, often quite emphatically, that Ubuntu has never seen any
> problems and therefore this problem is not important and no one needs to
> fix it.  It's hard for me not to characterize this as "willing to" leave
> dpkg in a state that I'd characterize as buggy.

I've certainly seen people state that the issues aren't important and
shouldn't be treated as blockers. I haven't seen people assert that
there are no issues at all without being corrected, just that they're
not important issues and not blockers. (That of course does not mean it
hasn't happened.) And I haven't seen assertions that we *shouldn't* fix
dpkg if dpkg is actually amenable to fixing.

If nothing else, the behavior of `dpkg -S` seems like a clear
counterexample that anyone on a usrmerge'd system can easily observe
themselves, leaving aside the more subtle issues with file migrations
and file conflicts. The debate over the severity of those issues seems
like it took place as part of the previous decision, though.

> I certainly agree that there are also other challenges in fixing dpkg.
> However, it would be nice if we could at least agree that it's necessary
> to fix dpkg, rather than arguing that it's fine to leave it in its current
> state.  (In fact, I suspect this belief that the current state is fine and
> reasonable to leave things in permanently is part of what's making it
> harder to discuss how to best fix dpkg in a way that is sustainable and
> supportable going forward.)

That's fair. It wouldn't surprise me at all if there are *multiple*
non-technical factors playing off each other here: expectation that
patches would be rejected, conflation between "not a blocker" and "not
an issue at all", and just general aversion to getting in the middle of
a flamewar-inviting issue. I do think this has become an adversarial
issue and gotten escalated excessively, which has absolutely compromised
the ability and inclination to fix it.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery  wrote:
> I think this accidentally confuses the related states of "unsupported" and
> "buggy."  We know that merged-/usr is buggy, in that one can construct a
> set of package operations that leave the system in an invalid state.  We
> have a project disagreement over how serious those bugs are.  No one is
> stepping forward to fix those bugs, which is indeed quite unfortunate.  I
> personally strongly disagree with the belief that simply because Ubuntu
> hasn't seen many instances of this class of bugs while using a package set
> where people have not moved files between packages and out of /lib and
> /bin very much if at all, it is acceptable to leave dpkg in that buggy
> state.
> 
> However, I think this is similar to many other disagreements over the
> severity of bugs, particularly ones that are hard to fix.  It doesn't
> really imply that this configuration is *unsupported*, which would mean
> that if someone had a system in that state and reported a problem we would
> say that we couldn't help them because their system is not in a supported
> configuration.  This is not the case; merged-/usr is supported in that
> sense.  Guillem may not be willing to support the user in that case but
> other people most certainly would.
> 
> That said, I personally am disappointed that the folks who have been
> pushing merged-/usr forward are willing to leave dpkg in a known-buggy
> state without attempting to patch it to fix the remaining issues.  I
> realize that there are various obstacles in successfully doing that, not
> all of which are technical,

I don't think "willing to" is a fair characterization here. It does not
seem at all obvious that such patches would have been accepted, given
the repeated vehement objections from the dpkg maintainer about the
chosen approach. Those objections did not invite contribution; at every
point, the assertion was that usrmerge was broken, not that dpkg needed
help supporting it. In particular, while I've seen the dpkg maintainer
call for implementing *different* approaches to merged /usr, I have not
seen even the slightest hint that patches implementing merged /usr in
the fashion the TC decided upon would be accepted.

I think those who might otherwise have been willing to write such
patches could be forgiven for thinking they'd be unwelcome.

I'm hoping that the TC may be able to address that exact issue.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, 24 Mar 2022 18:56:54 +0100 Helmut Grohne  wrote:
> On Thu, Mar 24, 2022 at 09:31:21AM -0700, Sean Whitton wrote:
> > We should distinguish two senses of "supported".
> > 
> > There is the sense of what Debian-the-project supports.  That is
> > specified in the TC decision.  That is not subjective.
> 
> This could be a language issue on my side. As I see it, the Debian
> project clearly endorses merged-/usr. I have difficulties calling it
> support, because that would go in hand with fixing the resulting
> problems - which is not happening. In my reading, support is an activity
> rather than a statement. That activity is missing. I even ran into
> /usr-merge fallout in 2022 myself. The statement is clear enough and
> Guillem's warning is clearly not helping the state of affairs.
> 
> > The difficulty is that Guillem's warning kind of refers to both.
> 
> Yeah, I see how you get there. It is fully in line with the confusion I
> see elsewhere.
> 
> Let us try to turn this upside down: How can Guillem express his
> dissatisfaction with the current process in a way that does not cause
> harm? Guillem has to deal with quite a number of /usr-merge-caused bugs.
> Many of them lack patches and/or are duplicating existing ones. In cases
> patches were posted (e.g. dpkg-shlibdeps), Guillem has included them.

There are two separate issues here: dissatisfaction with Debian's chosen
approach to the /usr-merge issue, and dissatisfaction with dpkg not
natively supporting Debian's chosen approach.

For the former, that decision is made, and while anything can be
*discussed* and a new decision could theoretically be made in the
future, that doesn't change or invalidate the decision as already made.
Delete the "usrunmess" script and most of the contents of the Dpkg
usrmerge "FAQ".

For the latter, that's *absolutely* reasonable. Even if (as extensively
discussed) larger issues don't tend to arise in practice, there are real
issues such as `dpkg -S` not handling search paths as expected (`dpkg -S
/bin/ls` vs `dpkg -S /usr/bin/ls`), as well as issues making it harder
to migrate packages to "natively" have files in /usr eventually. And if
users are filing bugs about such issues, it'd be entirely reasonable to
close or merge such bugs, referencing to one or a few bugs tracking the
lack of usrmerge support.

It would also be entirely reasonable to call for help fixing such
issues. It's entirely possible that someone would have written dpkg
patches *already*, if the pitched battles over usrmerge hadn't made it
abundantly clear how such patches would be received (and, at the moment,
likely *still* would be received). I think that has unnecessarily
delayed any efforts to actually help with this.

The maintainer script was not such a call for help, at all. And it has
already caused harm, and is continuing to do so.

As it stands, I think the path forward would be:

1) Delete the message from the maintainer script, immediately, and
   upload a new version of dpkg with that message removed. Don't add any
   new such user-targeted messages in that or other places (e.g.
   Description).
2) Issue a call for help *supporting* the established approach to
   usrmerge, not subverting and relitigating it.
   2.1) Make it clear that dpkg patches to fix issues related to
usrmerge, as well as updates to the documentation (including the
wiki), will not be unreasonably blocked on the basis of dislike
for usrmerge. (This will be necessary to make (2) successful.)
3) Delete `dpkg-fsys-usrunmess`.
4) File one or more bugs, or select existing representative bugs that
   don't have too much noise in them, about dpkg support for usrmerge
   (ranging from `dpkg -S` to the handling of files moving from / to
   /usr to the handling of file conflicts between packages).
5) Close or merge any new and existing dpkg bugs about merged /usr,
   pointing to the appropriate representative bug(s).

I think it would be appropriate for the TC to issue a ruling regarding
points (1), (2.1), and (3) above, and optionally to issue advice
suggesting (2), (4), and (5).

Re: Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

Russ Allbery wrote:
> I think the concern is less about the noise and more about the fact that
> this will be perceived by users as an official declaration from Debian as
> a project that their system configuration is unsupported, while
> simultaneously this is the default installation mode for new systems and
> something that we have elsewhere said is a correct system configuration.

Yes, this is exactly my concern. Especially given the text on the linked
wiki pages.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On March 15, 2022 11:38:44 PM PDT, Sean Whitton  
wrote:
>Hello Josh,
>
>On Tue 15 Mar 2022 at 03:14pm -07, Josh Triplett wrote:
>
>> It would appear that the situation has deteriorated further. dpkg 1.21.2
>> now issues a warning on all merged-usr systems:
>>
>> Setting up dpkg (1.21.2) ...
>> dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
>> dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.
>
>Does this happen just when configuring dpkg.deb here, or does the
>warning get issued at other times, have you seen?
>

Just dpkg. It's mentioned in the changelog.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

It would appear that the situation has deteriorated further. dpkg 1.21.2
now issues a warning on all merged-usr systems:

Setting up dpkg (1.21.2) ...
dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
dpkg: warning: See .

This escalation seems in direct contradiction to the tech-ctte decision
in 994388. Moreover, this seems to effectively use package maintainer
scripts as a means of directing a complaint at Debian users that has not
gotten traction in other forums, and then directing such users at a wiki
page that contradicts a prior project decision.

This does not even seem to be calling for help in any meaningful way.
For instance, soliciting help updating dpkg to handle such
configurations might have been more productive; that still wouldn't be
appropriate in a maintainer script, but it might have been productive in
a mail to -devel. But this isn't soliciting help, it's just incorrectly
declaring the user's system broken.

This seems counterproductive and harmful.

Re: Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

[Josh Triplett]

Jakub Wilk wrote:
> A few months ago I recompressed whole buster/main/amd64 to see what the 
> effect of ditching --compress-debug-sections would be.
>
> Raw data for this experiment is available here:
> https://github.com/jwilk/lets-shrink-dbgsym/releases/download/20200708/buster-main-amd64-20200708.tsv.xz

Thanks for collecting this data.

Based on this, I computed the top 50 packages by installed-size
increase, and the corresponding percentage increase:

insighttoolkit4-python-dbgsym_4.12.2-dfsg1-4+b1_amd64.deb   +5463M  +294.1%
libsimpleitk1.0-dbgsym_1.0.1-3_amd64.deb+3674M  +299.5%
libopenfoam-dbgsym_1812+dfsg1-2_amd64.deb   +3394M  +270.7%
libdeal.ii-9.0.1-dbgsym_9.0.1-1+b1_amd64.deb+3100M  +310.6%
polymake-dbgsym_3.2r4-4_amd64.deb   +2779M  +325.5%
libyade-dbgsym_2019.01a-2_amd64.deb +2378M  +309.7%
mrtrix3-dbgsym_3.0~rc3+git135-g2b8e7d0c2-3_amd64.deb+2252M  +343.0%
ceph-test-dbgsym_12.2.11+dfsg1-2.1_amd64.deb+1953M  +235.4%
ceph-test-dbgsym_12.2.11+dfsg1-2.1+b1_amd64.deb +1953M  +235.4%
firefox-esr-dbgsym_68.7.0esr-1~deb10u1_amd64.deb+1537M  +204.8%
freeorion-dbgsym_0.4.8-1+deb10u1_amd64.deb  +1480M  +489.2%
libreoffice-core-dbgsym_6.1.5-3+deb10u6_amd64.deb   +1417M  +176.0%
openfoam-dbgsym_1812+dfsg1-2_amd64.deb  +1364M  +302.0%
thunderbird-dbgsym_60.9.0-1~deb10u1_amd64.deb   +1230M  +196.5%
libtrilinos-stokhos12-dbgsym_12.12.1-7_amd64.deb+1176M  +301.4%
elastix-dbgsym_4.9.0-1_amd64.deb+1046M  +301.8%
qtcreator-dbgsym_4.8.2-1_amd64.deb  +1032M  +171.2%
cbmc-dbgsym_5.10-5_amd64.deb+982M   +233.5%
sumo-dbgsym_1.1.0+dfsg1-1_amd64.deb +976M   +297.3%
paraview-dbgsym_5.4.1+dfsg4-3.1+b2_amd64.deb+972M   +182.6%
thunderbird-dbgsym_68.7.0-1~deb10u1_amd64.deb   +924M   +263.0%
telegram-desktop-dbgsym_1.5.11-1_amd64.deb  +894M   +207.8%
ceph-osd-dbgsym_12.2.11+dfsg1-2.1_amd64.deb +853M   +234.9%
ceph-osd-dbgsym_12.2.11+dfsg1-2.1+b1_amd64.deb  +853M   +234.9%
seqan-apps-dbgsym_2.4.0+dfsg-11_amd64.deb   +852M   +363.4%
kicad-dbgsym_5.0.2+dfsg1-1_amd64.deb+837M   +225.6%
blender-dbgsym_2.79.b+dfsg0-7_amd64.deb +795M   +251.1%
libjulia1-dbgsym_1.0.3+dfsg-4_amd64.deb +791M   +183.3%
flang-7-dbgsym_20181226-2_amd64.deb +788M   +179.0%
fw4spl-dbgsym_17.2.0-2_amd64.deb+772M   +257.9%
krita-dbgsym_4.1.7+dfsg-1+b1_amd64.deb  +756M   +181.9%
libfreecad-python2-0.18-dbgsym_0.18~pre1+dfsg1-5_amd64.deb  +751M   +214.4%
libfreecad-python3-0.18-dbgsym_0.18~pre1+dfsg1-5_amd64.deb  +748M   +214.0%
libvtk7.1-dbgsym_7.1.1+dfsg1-12+b1_amd64.deb+719M   +189.6%
rocksdb-tools-dbgsym_5.17.2-3_amd64.deb +678M   +233.7%
ceph-common-dbgsym_12.2.11+dfsg1-2.1_amd64.deb  +657M   +247.1%
ceph-common-dbgsym_12.2.11+dfsg1-2.1+b1_amd64.deb   +657M   +247.1%
ncbi-blast+-dbgsym_2.8.1-1+deb10u1_amd64.deb+644M   +253.2%
libvtk6.3-dbgsym_6.3.0+dfsg2-2+b5_amd64.deb +638M   +188.5%
binaryen-dbgsym_68-1_amd64.deb  +633M   +226.5%
mothur-dbgsym_1.41.21-1_amd64.deb   +632M   +435.9%
ceph-mds-dbgsym_12.2.11+dfsg1-2.1_amd64.deb +627M   +202.8%
ceph-mds-dbgsym_12.2.11+dfsg1-2.1+b1_amd64.deb  +627M   +202.8%
horizon-eda-dbgsym_0.20181108-1+b1_amd64.deb+611M   +272.1%
spring-dbgsym_104.0+dfsg-3+b2_amd64.deb +589M   +234.5%
libtrilinos-muelu12-dbgsym_12.12.1-7_amd64.deb  +579M   +305.0%
regina-normal-dbgsym_5.1-6+b1_amd64.deb +563M   +255.5%
clang-tools-7-dbgsym_7.0.1-8_amd64.deb  +540M   +228.6%
libreoffice-calc-dbgsym_6.1.5-3+deb10u6_amd64.deb   +536M   +157.4%
clickhouse-common-dbgsym_18.16.1+ds-4_amd64.deb +531M   +217.6%


These size increases seem large enough to motivate promptly removing the
debug packages after using them.

Bug#976462: Bug#631985: Compress debug

[Josh Triplett]

On Mon, 25 Jan 2021 12:01:02 -0700 Sean Whitton  
wrote:
> On Mon 07 Nov 2011 at 06:34PM +01, Bastien ROUCARIES wrote:
> > I agree it could be done by default with compat 9. Will decrease the
> > size of archive also. I need more than 10G in order to debug kde...
> 
> Does this sort of thing still apply in 2021?

Yes.

Apart from the running joke that the persistent state of most disks is
"full", this remains relevant because it can make the difference between
"leave the debug symbols installed, keep them updated, and be able to
debug quickly the next time" versus "install debug symbols, debug,
remove debug symbols until they're next needed".

- Josh Triplett

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Josh Triplett]

On Mon, 30 Nov 2020 10:55:44 + Mark Hindley  wrote:
> On Sun, Nov 29, 2020 at 11:58:15PM +, Simon McVittie wrote:
> > On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote:
> > > #921012 is about changing network-manager to Depend upon "default-logind |
> > > logind" rather than libpam-systemd
> > 
> > This is a change that is *sometimes* appropriate, but sometimes not,
> > depending on what facility the dependent package intends to receive
> > from the dependency. It needs to be assessed on a case-by-case basis,
> > and cannot be done mechanically across the distribution.
> > 
> > default-logind | logind is appropriate if the package's needs are
> > limited to "something that looks sufficiently similar to systemd-logind"
> > (like for example policykit-1, where I applied exactly that change),
> > but is not appropriate if it needs other systemd-specific facilities
> > (like for example dbus-user-session, which currently needs a working
> > `systemd --user` and has no way to function correctly otherwise).
> > 
> > I haven't fully investigated what facilities NM requires from
> > systemd. According to #921012 it requires hostnamed in its default
> > configuration, and according to the Gentoo wiki it expects to see
> > /etc/machine-id for DHCPv6. There might be others.
> 
> In my testing, network-manager works without issue using libpam-elogind. It 
> does
> not require 'systemd -- user' and falls back to legacy implementations if
> hostnamed is not available.

Which would then make those legacy fallbacks load-bearing, when they
previously were not. If (hypothetically) network-manager upstream
decided to remove those legacy fallbacks, the maintainer would then be
in a position of either:

1) not noticing, and having users experience breakage that could have
been foreseen, in addition to one of the following two options,

2) changing the dependency accordingly to reflect the new hard
requirement on hostnamed, and potentially finding themselves hauled in
front of the TC *yet again*, or

3) maintaining a downstream patch forever. This would, again, put
someone in the position of having to maintain support for alternative
init systems, which the GR does not require any maintainer to do. And
keep in mind that rebasing patches for new upstream versions isn't
typically work that can be offloaded, even if someone were willing to do
so; the nature of such work is that it typically has to be done all at
once.

This would be a much more reasonable request if the alternative
implementations provided a version of hostnamed (and anything else
network-manager relies on), such that network-manager could
transparently rely on such functionality without having to implement a
fallback itself. With the fallback code provided within the alternative
implementations themselves, that would ensure that any bug reports on
that fallback code would *also* be the responsibility of the alternative
implementations.

> > I think we have three options:
> > 
> > * overrule the NM maintainer on both #921012 (logind dependency) and
> >   #964139 (init script inclusion) as you ask;
> > * decline to overrule the NM maintainer on either point;
> > * overrule the NM maintainer on #921012 but do not overrule on #964139, and
> >   instead expect the init script to be provided by some other package that
> >   is maintained by people who are interested in non-systemd init systems
> > 
> > I don't think it would make any sense to overrule on #964139 but
> > not on #921012, because if NM depends on libpam-systemd (which
> > requires/assumes systemd as pid 1), then people who want to use non-default
> > init systems will remain equally unable to use NM. Do you agree?
> 
> I agree fully. However I would also propose the inverse logic: #921012 appears
> to be resolvable in that NM works with elogind without problems and 
> exploration
> of alternative technologies such as elogind was explicitly included in the
> winning GR option. But to overrule #921012 but not #964139 would also make
> people who want to use non-default init systems still equally unable to use 
> NM.

Only until, as observed in the mail you're replying to, someone
interested in an alternative init system implements a solution for:
> putting init-system integration in a place where the maintenance
> responsibility and effort rests with those who are interested in
> supporting the relevant init system.

Bug#971515: Status as of last tech-ctte meeting

[Josh Triplett]

 base on which other people would
> build things, rather than a comprehensive collection of tools that covers
> all the incidental things you need from a computer, and where people need
> only reach outside of Debian for the thing on which they're doing primary
> development and thus need the bleeding edge and the flexibility of using
> unreleased or unpackaged code.
> 
> I think it's going to be challenging for Debian to continue to be that
> universal toolbox, but I also think it's exciting and valuable.  I still
> want to try to achieve it, and I would rather adopt new strategies for
> packaging that make life simpler and easier for packagers and allow us to
> keep pace with more upstream packages than to reduce scope to only the
> things we already know we're good at.

This is an excellent summary of the issue, tensions, and values
involved. Thank you, Russ; you continue to be a major voice of clarity,
even-handedness, and genuine considerate deliberation.

In particular, I think you've captured the key values that are in
tension here, and the tradeoffs that Debian faces. As you said, it's
hard for us to re-evaluate things that have been deeply ingrained and
feel like core values. Some of the biggest problems Debian has faced
involve tension between multiple values, and those are precisely the
problems that grow most bitter and challenge our ability to genuinely
change our minds. Many people treat "these are my/our values" as the
*end* of a discussion, rather than the point at which the discussion has
a chance of making major progress.

I've encountered this same tension and tradeoff (vendoring vs not
vendoring) in various contexts, and worked in ecosystems at different
points on that spectrum. Your message gives me a great deal of hope and
optimism for how Debian may tackle this problem.

In particular, with my upstream Rust/Cargo hats on, I would love to work
with you and others on questions of what software packaging could look
like, and how to maintain the quality and curation *and* package
availability of Debian in collaboration with other ecosystems of package
and dependency management.

Other potentially interesting questions: what are the assumptions that
go into our current tradeoffs about shared libraries vs static
libraries, and are those still the correct tradeoffs in all cases?

Josh Triplett

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Josh Triplett]

On Thu, 19 Nov 2020 13:04:56 -0700 Sean Whitton  
wrote:
> On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> > First, as a point of order (for which some authoritative guidance from
> > the Secretary, CCed, would potentially prove useful): while the
> > technical committee is empowered to handle various types of disputes (up
> > to and including overruling an individual developer if necessary), I do
> > not believe it falls within the scope of the technical committee to
> > override a decision already decided by a project-wide GR, or to
> > "interpret" the text of a GR issuing a nontechnical policy document in
> > ways that may undermine the decision made in that GR and document.  Any
> > interpretation of the text of the GR would need to be based on the text
> > and intent of the GR. (Intent could include discussion at the time, but
> > would notably include the text of other options that did not prevail, as
> > well as the status quo at the time that motivated a GR to change.)
> > Changing that intent would require either another GR, or (per specific
> > provisions included in the winning GR option) consensus among the
> > project, not a TC ruling.
> >
> > Concretely, the GR explicitly acted by "Using its power under
> > Constitution section 4.1 (5)", which is the power to "Issue, supersede
> > and withdraw nontechnical policy documents and statements.". The
> > Technical Committee does not have such "nontechnical policy documents
> > and statements" within its ambit. Any interpretation of 'what it means
> > to "support the efforts of developers" working on support for
> > alternative init systems' would thus be an interpretation of such a
> > nontechnical policy document.
> >
> > Thus, I would suggest that the technical committee should decline to
> > rule on any matters already decided by the GR. This does not preclude
> > the TC from offering advice, or potentially facilitating dispute
> > resolution if asked to do so, or even as a *last resort* overruling a
> > developer on a specific technical matter (if doing so does not go
> > against the GR), but I don't believe it's within the scope of the TC to
> > relitigate the GR to mandate support for alternative init systems. Any
> > potential ruling here would need to avoid attempting to supersede the
> > GR.
[...]
> In our dispute resolution role, the TC is empowered to decide upon the
> two things about the contents of the network-manager package that we
> have been asked to decide upon, as a matter of last resort.  No-one
> disputes that we can do this.

(I agree with this paragraph, in case there was any doubt about that.)

> We have also been invited to rule that "Similar init-compatibility
> changes should not be blocked by package maintainers unless they are
> defective on their own merits".  Essentially we are being invited to
> generalise the decision that we make about the network-manager package
> to say that it would apply to similar cases.
> 
> We might decide that the reasons we have for whatever decision we make
> about the network-manager package do not generalise, and so we may
> decline the invitation to make any more general ruling.
> 
> But if we do think the reasons generalise, then we can generalise our
> ruling without stepping outside of our dispute resolution role.  For
> example, we might say "if another CTTE bug was filed about the contents
> of a package which was similar to this one in the following respects
> ... then we would expect to issue the same ruling as we have here,
> because we believe that our reasons for this ruling would apply to all
> packages which are similar in the previously stated respects."
> 
> Clearly we would not want to say anything which we thought contravened
> the GR.  However, I do not think there is any reason to think that
> resolving this dispute would necessarily involve the TC interacting with
> the GR in a way that the constitution does not permit.  We are being
> asked to decide about one package, and being invited to generalise in a
> way that falls within the scope of our dispute resolution role.

It would certainly be *possible* for the TC to suggest that it would
systematically rule in favor of, to use these two issues as examples,
including init scripts and alternative dependencies despite the
maintainer not wishing to maintain them. What I'm suggesting is that,
given that the slate of GR options included possibilities that would
have required maintainers to do so by policy, and the developers
declined to enact such a policy, it would be *especially* unfortunate if
the common practice became to either systematically esc

Bug#975075:

[Josh Triplett]

[I have consolidated responses to multiple bits of quoted text here, in
an effort to consolidate responses to variations on the same points, in
the hopes that doing so will avoid proliferating variations on a common
theme.

Also, the title of this bug itself presumes a disputed point of view.]

On Thu, 19 Nov 2020 11:40:20 + Ian Jackson 
 wrote:
> Josh Triplett writes:
> > I do not believe it falls within the scope of the technical
> > committee to override a decision already decided by a project-wide
> > GR,
> 
> No-one is asking the TC to override the GR.  In fact, Matthew is
> asking the TC to *implement* the GR.

> > One major aim of the GR (https://www.debian.org/vote/2019/vote_002) was,
> > in large part, to settle with finality many ongoing case-by-case
> > disputes about alternative init system support,
> 
> I think that was the aim of the proponent.  Unfortunately, the winning
> option did not support that desire.

That is an adverse interpretation that I do not believe is supported by
either the text of the GR or the intentions of those voting for it.

I would also like to make the observation that, both during the voting
for the GR *and* shortly after the GR, people opposed to this GR
repeatedly stated that the winning option would allow package
maintainers to decline to support alternative init systems if they did
not wish to support a proposed change; some of those opposed to this GR
outcome even suggested that it would make systemd effectively mandatory.
(This has not turned out to be the case, in practice.) I find it
interesting that that was the stated interpretation used to oppose the
GR and subsequently bemoan the outcome, but yet now an alternative
interpretation surfaces that would paint the outcome as though there
were a *mandate* for maintainers to always support alternative init
systems.

To be clear: I don't believe the intent of the GR was for all package
maintainers to *systematically* remove init scripts or alternative init
support, and I don't believe that's what happened here. If I believed
that there was some ill intent here to destroy alternative init systems
(rather than simply a desire to avoid expending time and energy on
them), I would not look favorably on that. I also don't believe that the
intent of the GR was to *force* maintainers to merge alternative init
support. Given the evident desire of some package maintainers to avoid
expending effort in ongoing maintenance of support for alternative init
systems, it would have been desirable to seek alternatives that remove
that burden from the package maintainer, and shift it to those working
on alternative init systems. Instead, it appears that the moment a
package maintainer declined the solution that would be the least work
for those working on alternative init systems, the matter was escalated
to the TC rather than seeking alternatives.

To the extent the TC wishes to solve the more general problem rather
than the specific case, I would propose that honoring the intent of the
GR would be to request potential solutions that appropriately
compartmentalize the work of maintaining alterntive init support to
remove it entirely from the package maintainer. The TC does not do
detailed design work to generate alternatives that were not put before
it, but it would certainly be within the remit of the TC to request that
others do so, and to evaluate such alternatives if a consensus cannot be
reached. But as far as I can tell, there was *no* apparent effort to
propose any such alternatives; the matter was simply taken to the TC
once the first proposal was declined.

This is *not* as simple as "just merge the init script and Depends
change". It has also included other ongoing work each time a new
compatibility issue arises. Past evidence suggests that this has proven
to be a source of ongoing maintainer burden, despite claims to the
contrary.

> > or to "interpret" the text of a GR issuing a nontechnical policy
> > document in ways that may undermine the decision made in that GR and
> > document.
> 
> Obviously the TC ought not to undermine the GR.  What counts as
> undermining the GR and what counts as implementing appears to be a
> matter of debate.

So it would unfortunately seem. One would have hoped we were all debated
out after the GR, and that the GR could stand as evidence of the outcome
of that debate.

As stated in my previous mail, the *least* favored option in the GR vote
was "Further Discussion", and yet here we are, having Further
Discussion.

> > Any inclusion of work into a package necessitates *some* amount of
> > development and packaging resources by the maintainer of that package.
> 
> This is true of course.  But that is the key role of the maintainer.
> As recognised in the GR text.

The maintainer is also empowered to decide whether or not to include any
given change

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Josh Triplett]

On Thu, 19 Nov 2020 12:00:45 -0700 Sean Whitton  
wrote:
> Hello,
> 
> On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:
> > I'd also like to address one other issue here. It would be easy to
> > hypothesize, at this point, that some additional communication (or more
> > verbose communication) from the maintainer might have helped here.
> > However, I would express doubt that any more verbose version of "no"
> > (e.g. a long-form explanation about undesired additional maintenance
> > burden) would have led to any less escalation. I think the situation
> > would still have ended up here, no matter how much time or energy was
> > expended in writing responses.
> >
> > That seems particularly likely given the adversarial NMU directly
> > attempting to override an active package maintainer's decision, which
> > escalated the situation further. (Such adversarial NMUs have occurred in
> > regard to alternative init support in the past, as well.) And I don't
> > think anyone can reasonably suggest that they thought the change was
> > made unintentionally (given that it was explicitly mentioned in the
> > changelog), which makes the NMU a rather hostile escalation.
> >
> > I would ask anyone on the TC who feels that more verbose answers were
> > desirable whether they think a more verbose answer would have had any
> > effect on the outcome or subsequent escalations.
> 
> Assuming for a moment that the TC does not decline to rule, it is going
> to be very hard for us to make a good decision if we lack more detailed
> input from the package maintainer.

I'm not suggesting otherwise; I'm only asking the TC to refrain from
suggesting that further communication alone, prior to this point, would
have averted this situation. The original request makes such
implications, so they may potentially have formed part of what the TC
ruled on. (The TC does sometimes issue similar suggestions as part of
its rulings, in what I think is generally a *good* practice of
encouraging people to work things out and giving them guidance on how to
do so.)

> We can speculate as to whether the dispute would have proceeded better
> or worse with more verbose messages from Michael before now, but it
> would be beside the point.

Thank you; that fully addresses this particular point.

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Josh Triplett]

top. It's also worth
noting that many of those requests came from the same set of people in
favor of alternative init support, which makes "alternative init but
with network-manager installed" an even smaller subset of users than
"alternative init".  Given the outcome of those requests (making it
possible to install GNOME without network-manager), and the
corresponding burdens placed on GNOME and network-manager maintainers,
one would hope that it was in fact quite possible to use Debian and even
GNOME without network-manager. If Debian were not usable without
network-manager, then that would suggest those additional maintenance
burdens were imposed unnecessarily, and we should lift them.

> Both bugs have sat open for extended periods with no input from the
> maintainer;

The bug did in fact have input from the maintainer, the day it was
filed: it was tagged as wishlist. That seems like a generous response to
a report directly asking for the reversion of a change documented in the
changelog. It's possible that the maintainer intended it to remain open
for documentation purposes, or that the maintainer might have desired to
tag it "wontfix" but expected (based on past evidence) that doing so
would lead to more rapid escalation.

I certainly don't think that is sufficient cause to make an adversarial
NMU reverting a maintainer's intentional change.

> I'm afraid the effect of this is that the maintainers of this package
> are making it impossible for other developers to enable support of
> sysvinit.

This is not the case. If the maintainers of this package decline to
*integrate such support in the package*, that does not close off all
paths to providing such support. Other paths to enablement would include
separate packages, other network management software, or alternative
distributions. I'm sure there are other potential alternatives as well.

- Josh Triplett

Bug#947847: please install systemd-sysusers using update-alternatives

[Josh Triplett]

On Mon, Jan 27, 2020 at 06:16:14PM +0100, Svante Signell wrote:
> It is as simple as:
> if ps -p1|grep -q "systemd"; then

This is not the correct way to detect whether systemd is the current
init system. You want:

if test -d /run/systemd/system; then

See https://www.freedesktop.org/software/systemd/man/sd_booted.html

>  
> else
>  
> fi

"exec", not "install".

- Josh Triplett

Policy and procedures issue: init package hijacked via hostile NMU (declined by maintainers)

[Josh Triplett]

[Please don't CC me on responses, and please follow up solely to -devel rather
than cross-posting.]

Please note in the following mail that I'm raising this *exclusively* as a
policy and procedures issue, *not* a technical issue. I would request that
people *please* focus on the policy and procedures issue, and keep any proposed
technical solutions to the specific problem at hand (or comments on init
systems) to another thread. There is already another thread on -devel regarding
technical approaches to handling init systems, and if people wish to help debug
issues a specific init system they should do so in an appropriate bug report.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838480 . Rough
summary of events:

- Dmitry Bogatov requested that the init metapackage depend on
  runit-init (to enable runit as an alternative init system).
- After a few months of back and forth, runit was updated to include
  appropriate scripts for compatibility with expected interfaces of
  init.
- Dmitry popped up again after two years, in October, and then in
  November said that he'd upload an NMU to DELAYED soon.
- Martin Pitt promptly responded with a report that a system installed
  with runit-init appears broken, and in particular appears to hang
  without any ability to log in.
- Dmitry reported back that it "works for him", and no further debugging
  appears to have taken place.
- Dmitry uploaded an NMU to DELAYED/15.
- One of the maintainers of the init metapackage requested the cancellation of
  that NMU, on the basis of Martin's report of brokenness and the lack of any
  debugging.  The maintainer suggested some possible paths forward (as well as
  further testing).
- Dmitry refused to cancel the NMU, which then went into the archive.
- *After* the upload went through, Dmitry started proposing a mail to
  the tech-ctte.

As such, the Essential init package seems to have been hijacked by a
hostile NMU refused by the maintainer. This NMU and its hijacking of the
package was not discussed anywhere else (such as -devel or -ctte), was
not approved by anyone else, and appears to be effectively a unilateral
action on the package regarding a wishlist bug.

I am making the assumption that, in the 11 hours between that refusal
and the hijacking NMU entering the archive, no entirely unforeshadowed
behind-the-scenes discussion between the maintainer and Dmitry took
place in which the differences were settled amicably and the debugging
of this critical package was completed to everyone's satifaction.

There are times that it can make sense to take over a package or upload
an NMU without the agreement of the maintainer. Those circumstances
normally occur 1) when the maintainer has provided no feedback or
response (not the case here), 2) when some further discussion has
occurred in a broader body to seek consensus (which was not done here),
or 3) when a developer has been overruled through the proper processes
and channels within Debian (which has not occurred here). And in any
case, those circumstances do not normally occur in a hurry.

Bug#862051: Refer #862051 to ctte

[Josh Triplett]

On Fri, 14 Jul 2017 17:50:56 +0200 Tollef Fog Heen  wrote:
> === DRAFT Resolution ===
> The Technical Committee recognises that circumstances change in ways
> that make previous resolution no longer appropriate.  In 2012, it was
> resolved that the nodejs package should not provide /usr/bin/node due to
> the historical conflict with the ax25-node package.  Node.js is still
> quite popular and the ax25-node package is no longer in the stable,
> testing or unstable so the requirement for nodejs to not provide
> /usr/bin/node no longer applies.

There's a missing (or extra) word here. s/unstable/unstable archive/, or
s/in the stable/in stable/.

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[Josh Triplett]

On Sun, 25 Jun 2017 23:37:13 +0100 Colin Watson <cjwat...@debian.org> wrote:
> I could arrange for the relevant grub2 postinst scripts to remove
> /etc/default/grub.d/init-select.cfg entirely when appropriate conditions
> apply.  In addition to a self-defence argument, this is further
> justified by the fact that grub2 now provides a similar facility of its
> own as of 2.02~beta2-20: if other init daemons are installed, then
> grub-mkconfig generates additional menu items for them (although there
> are no arrangements to migrate the default choice from
> /etc/default/init).  This would still violate policy §10.7.3/10.7.4,
> although it seems to be the favoured option of the debian-devel thread,
> and it is the least bad option I can see so far.

This seems very reasonable. However, to avoid even the remote chance of
losing user data, you should include hashes of all shipped versions of
init-select.cfg or possible generated versions of it for various init
systems, and if the file doesn't match one of those, move it aside to a
backup location and provide a notice to the user that you've done so.

- Josh Triplett

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

[Josh Triplett]

On Fri, Jan 13, 2017 at 10:04:34AM -0500, Sam Hartman wrote:
> >>>>> "Josh" == Josh Triplett <j...@joshtriplett.org> writes:
> 
> Josh> As another technical alternative, which I haven't seen
> Josh> mentioned elsewhere in this thread or related bug reports:
> Josh> when I need to override a packaged binary or file temporarily
> Josh> for debugging purposes, without forgetting to restore it
> Josh> later, I tend to use "mount --bind /my/replacement
> Josh> /usr/bin/foo".  For instance, for local testing while
> Josh> developing dh-cargo, which required a newer version of Cargo
> Josh> than packaged in Debian at the time, I built a local version
> Josh> of Cargo and did "mount --bind ~/src/cargo/target/debug/cargo
> Josh> /usr/bin/cargo".  That allowed me to easily test-build
> Josh> packages before the availability of a Debian package of a
> Josh> sufficiently new Cargo.
> 
> O, cool, that's really need.
> 
> And as a throw-back to an alternate Plan9 history, you could presumably
> unshare your mount namespace and even do that for a subset of the
> processes on a system, getting almost all the benefits of PATH.

Yes.  Years ago, when Debian transitioned /bin/sh from bash to dash,
Marco d'Itri posted a sample workaround for any scripts assuming bash,
which involved unsharing the mount namespace, bind-mounting /bin/bash
over /bin/sh, and then exec'ing a program.

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

[Josh Triplett]

On Wed, 11 Jan 2017 13:51:27 -0500 Daniel Kahn Gillmor  wrote:
> Please do not do this to gpg-agent unless upstream is fine with this
> change.  I have more important things i want to consider divergence from
> upstream about, and i don't think this particular scenario is a healthy
> use of debian policy.
> 
> I laud Ian's goals of making debugging easier, but the particular
> pattern he describes (wrapping stuff and putting the wrappers in $PATH)
> is not the only way to ease debugging, and is at least as vulnerable to
> the problems he associates with other techniques ("too easy to forget to
> put back", etc) as they are.

As another technical alternative, which I haven't seen mentioned
elsewhere in this thread or related bug reports: when I need to override
a packaged binary or file temporarily for debugging purposes, without
forgetting to restore it later, I tend to use "mount --bind
/my/replacement /usr/bin/foo".  For instance, for local testing while
developing dh-cargo, which required a newer version of Cargo than
packaged in Debian at the time, I built a local version of Cargo and did
"mount --bind ~/src/cargo/target/debug/cargo /usr/bin/cargo".  That
allowed me to easily test-build packages before the availability of a
Debian package of a sufficiently new Cargo.

This technique also has the advantage of vanishing on reboot, reverting
back to the system binary.

This seems appropriate for a local debugging technique with a temporary
lifetime.  Such local interposition hacks help determine or debug a
solution to some problem, which should ideally then lead to a fix to the
software itself, fixing the problem for everyone and allowing the
software to work out of the box for more people.

Bug#850967: Clarify /usr/bin/foo should not be hardcoded even in upstream parts

[Josh Triplett]

On Wed, 11 Jan 2017 14:59:06 -0500 Sam Hartman  wrote:
> I'll note that the practice of hard-coding paths is fairly common.
> 
> 
> One common cause for this is programs that don't want to rely on PATH
> for calling exec.  Systemd is a particularly interesting example.
> ExecStart and related arguments in systemd units are required to include
> full paths.
> 
> I am very uncomfortable with the idea of setting policy here.  I find I
> tend to agree with Daniel's position a bit more than Ian's.
> In particular, I definitely think that for closely-related versions of
> software, making sure the same versions are used is helpful.
> I've hurt myself more by having parts of something built in /usr/local
> than I have not being able to override things for debugging.
> However, I
> think that both parties have valid points.
> So, I'd be much more comfortable if we wanted to help make people more
> aware of the tradeoffs than I would setting policy.

I've likewise run into far too many debugging and triage adventures
involving a program not running what it thought it was running, or for
interpreted languages, picking up a random local version of a module.
(At this point, when helping debug something on someone else's system, I
check early on for issues related to loading local copies of things
fairly early in the process.)  Today's clever hack becomes tomorrow's
technical debt.  And the more certainty a sysadmin has that they'd never
forget they had a locally installed override/hack, the deeper the
head-shaped indentations in the nearest desk or wall when it turns out
they do.

I don't want to argue that we should never invoke programs via $PATH, or
that we should never invoke programs via full pathnames.  I can see
cases for both.  Rather, I'd agree with Sam Hartman's comment above that
we should document both approaches and the tradeoffs between them.  But
in terms of ecosystem fragility, it seems far worse to have the software
in Debian behave differently in this particular regard than the software
upstream, making it even more challenging to debug.

I find it surprising that this has ended up in front of the Technical
Committee before it has, for instance, ended up on debian-policy or
debian-devel for discussion.  While Policy would not make a change that
would instantly declare a large number of packages de-jure buggy, those
two lists nonetheless seem like the right place to have this discussion
outside the context of any particular package.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Josh Triplett]

On Fri, 26 Aug 2016 14:14:25 +0100 Ian Jackson 
 wrote:
> Sam Hartman writes ("Re: Bug#835507: Please clarify that sysvinit support 
> decision is not going to expire"):
> > I don't want to make a blanket statement that it's a bug not to include
> > an init script.  The systemd package includes a number of daemons and
> > services and installs no init scripts, and no really, that actually is
> > the right answer for that package.  Policy should basically means bug of
> > normal severity.  (I've always wished that the policy people would be a
> > bit more nuanced especially when taking a term from RFC 2119, which
> > more-or-less already includes the nuanced language they need, but
> > people seem to do a fairly good job of accepting the nuances even though
> > that's not quite what policy says.)
> 
> You could say that missing sysvinit support is a bug unless there's a
> good reason why this particular package ought not to support sysvinit.

This seems like a completely reasonable thing for Policy to say.  It
actually doesn't say that today (see Policy 9.11), but I think it
should.

Assuming Policy does say that, then that seems like a sufficient
justification to 1) file a bug and 2) provide or seek out help fixing
that bug.  (Right now, Policy provides enough justification to file a
"Severity: serious" bug, but that doesn't seem reasonable; a
normal-severity bug does, though.)

In the case of conntrack-tools, has anyone actually filed a bug, or
offered to help?

> > I think including 6.1.5 language saying that we encourage maintainers to
> > merge patches adding support for init systems including init scripts
> > would be valuable.
> 
> That would be good.
> 
> I think what is really needed is a clear statement from the TC that
> support for sysvinit should not be regarded as transitional or
> time-limited.

That's a question of available volunteer time.  I don't think sysvinit
support should be regarded as "time-limited"; I don't, for instance,
think "that was two years ago" in isolation serves as a reasonable
argument for ignoring sysvinit.  However, I do think it's reasonable to
expect people who want it to work to provide assistance keeping it
working.  For instance, if someone filed a bug on the sysvinit support
in a package, it seems reasonable for the maintainer to tag it "help".

And if upstream of a package starts requiring systemd and drops support
for sysvinit, I think it's reasonable for a maintainer to send a note to
debian-devel and similar asking for volunteers to maintain a version of
that software with sysvinit support, and to talk with those volunteers
about what shape that maintenance should take (e.g. working with
upstream, providing a new upstream, providing patches to the existing
pakage).  Dropping such support the moment upstream does without any
warning seems unreasonable.

Bug#835507: Please clarify that sysvinit support decision is not going to expire

[Josh Triplett]

On Fri, 26 Aug 2016 12:55:56 +0100 Ian Jackson 
 wrote:
> So: would the TC please clarify that the decision that
> 
> For the record, the TC expects maintainers to continue to support
> the multiple available init systems in Debian.  That includes
> merging reasonable contributions, and not reverting existing
> support without a compelling reason.
> 
> still stands, and that the answer to this queston
> 
>However, that was two years ago. How long should we be expected to
>continue maintaining sysvinit scripts?
> 
> is "indefinitely, and specifically until a contrary decision by the
> TC" (subject to quibbles over the exact meaning of "maintaining").
> 
> Or to put it another way:
> 
>   The answer to "is missing sysvinit support a bug" is "yes, and
>   it will continue to be regarded as a bug until further notice".
> 
>   Of course a maintainer is not required to personally fix every bug,
>   but a maintainer should not introduce bugs without good reasons, and
>   should merge reasonable bugfix contributions.

Policy *already* defines it as a bug (in terms of failing a "must") to
not supply sysvinit support.  Quoting Policy 9.11:
> any package integrating with other init systems must also be
> backwards-compatible with sysvinit by providing a SysV-style init
> script with the same name as and equivalent functionality to any
> init-specific job, as this is the only start-up configuration method
> guaranteed to be supported by all init implementations. An exception
> to this rule is scripts or jobs provided by the init implementation
> itself

If anything, Policy needs some fixes to even allow for the *possibility*
of packages that can only work with systemd.  There's no current
exception in Policy that allows for packages that specifically depend on
systemd functionality unavailable in sysvinit.  For instance, a package
that uses socket activation and intentionally has no support for running
as a standalone daemon would likely want to integrate with inetd as an
alternative rather than integrating with sysvinit, but Policy doesn't
actually allow a package to do that.  Today it'd be a Policy violation
to ship a package that supports running via either systemd or inetd,
because running via systemd triggers Policy 9.11 and thus requires a
"SysV-style init script", even when that wouldn't be appropriate.

The reaction to every single instance of someone finding it a pain to
maintain sysvinit support should not be "as a reminder, the TC has a
giant hammer and will hit you with it".  The reaction should be "are
there people willing to *help* maintain sysvinit compatibility, who
actually use it, who will notice when it breaks, and who will send
patches?"

And the answer to "how long should we continue maintaining sysvinit
scripts" is "as long as someone is willing to step up and do the work".
(That's also, for instance, the answer to "how long should we maintain
an architecture", and many other similar questions.)

I do think that developers (*not* the TC) with an interest in sysvinit
support should explicitly say that if anyone needs help maintaining
sysvinit support for their package, they'd be willing to volunteer to
provide such help.  Anyone willing to volunteer for that?

Re: Fwd: Re: Debian Roadmap discussion ?

[Josh Triplett]

Mehdi Dogguy wrote:
> Forwarding my reply to the list.
>
> My mail got rejected because leader@ is not subscribed to tech-ctte...
> What a pity :)

I'd suggest subscribing lea...@debian.org to the "whitelist" list
(https://lists.debian.org/whitelist/), which exists for exactly this
purpose.

- Josh Triplett

Bug#797533: New CTTE members

[Josh Triplett]

Anthony Towns wrote:
> Having an immediate vote (that often results in FD) everytime a new ctte
> bug gets filed seems like a plausible approach to ensure people get a
> quick initial response from the ctte though? eg:
> 
>   Bug#776708 arrived two hours ago. Let's vote!
> 
>   Resolution: overrule gcc maintainer for cross-gcc-support
>Options:
> - Overrule maintainer (3:1 majority)
> - Leave as is -- decline submitter's request
> - Further discussion
> 
>   Votes:
> Alice: Overrule > FD > Leave as-is
> Bob:   FD > Leave as-is > Overrule
> Carol: FD > Leave as-is > Overrule
> Dave:  Leave as-is > FD > Overrule
> Emma:  FD > Overrule > Leave as-is
> 
>   Outcome beyond doubt 24h later: FD > * (4:1)
> 
> would not make a decision or require too much immediate thought on behalf
> of the ctte members -- heck even the bug log wouldn't have been very long
> at that point -- but it would probably give the submitter and maintainer
> a good feel for where they stand ("Oh, it's not obvious to everyone sane
> that I'm write and they're wrong? Huh.").

Assuming that the "often results in FD" holds true, and that this doesn't
encourage snap judgements, this seems like a very good idea to me.

(That said, I would suggest in particular that the ctte exercise extreme
caution if the bug log does not show evidence of a maintainer response
that demonstrates an irreconcilable situation.  The ctte should still be
a *last* resort.)

- Josh Triplett

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Josh Triplett]

 format; consumers of
  .desktop files that can't handle current image formats could always
  translate it back, though adding support for current image formats
  provides more benefit for comparable effort.

Finally, as a last resort, while option D says you can't ship a menu
file if you also ship a .desktop file, you can still ship a menu file
*instead* of a .desktop file, if you really want to.

Based on the above analysis, I don't see a single instance of menu
metadata that wouldn't translate over to .desktop files.

- Josh Triplett

Bug#636783: Bug#795855: #636783 - New bugs for individual issues

[Josh Triplett]

On Tue, Aug 18, 2015 at 08:23:44PM +0200, Steve Langasek wrote:
 On Tue, Aug 18, 2015 at 11:12:08AM -0700, Josh Triplett wrote:
  On Mon, 17 Aug 2015 15:39:06 +0200 Didier 'OdyX' Raboud o...@debian.org 
  wrote:
   - #795855
 Introduction of formal cloture vote for the TC
 
   - #795857
 TC chair appointment
 
  Given context, I think these originally shotgunned proposals (especially
  these two) need careful re-evaluation, to figure out how much actual
  point they have and how much they're just a reflection of a past spite.
 
  The cloture proposal honestly seems like a needless pile of additional
  process.  Anyone can call for a vote at any time, and I don't think
  that's a bug; if people agree that a vote is warranted, they can vote,
  and if they don't, they can vote further discussion.  If even a simple
  majority is opposed to holding a vote, they can all vote Further
  Discussion.  Anyone else can *also* call for a vote at any time, if
  they feel there's another issue to discuss.
 
  So, I would suggest that the cloture proposal should be consigned to a
  historical note along with the fit of pique it came from.
 
 This was no fit of pique.

To clarify explicitly, since I realized that my offhand comment may not
have been entirely clear: I was not suggesting that your considered
proposal for cloture was a fit of pique; that would be ridiculous.  I
was suggesting that the original series of sudden complaints about TC
processes and composition, as a whole, constituted a fit of pique.  Or
perhaps a full-fledged tantrum of pique.  Your proposal, while I
disagree with it, nonetheless seems like a genuine and considered
attempt to consider and address one of those particular complaints.

 I consider the fact that any single member of the
 TC can cut short discussion by calling a vote to be a serious bug in a
 process that is otherwise designed to favor consensus instead of mere
 majority rule.  It is precisely at those times that the TC has not found
 consensus that the process should be proofed against procedural abuses

Even if you consider this an issue, I don't think this is the right way
to fix it.

I think it makes sense to retain the ability to call for a vote on a
specific question at any time.  But at the same time, it should be
*explicitly* clear that Further Discussion is always a viable option,
and furthermore, there should be a straightforward way to say cut that
out.  Thus, rather than voting on whether to vote, the TC can simply
vote, which will either result in an answer, *or* (determined by the
same vote) result in an expression of dissatisfaction with the current
proposals and a desire to seek other options.

I would also suggest that the TC has encountered this situation
precisely once in a long history of decisions (including fairly
controversial decisions).  (There were plenty of situations where the TC
was too quick and eager to take action, but only one where anyone at all
suggested that a TC member was too quick to call for a vote.)  And I
would further suggest that that situation was rather unique to the
particular type of decision requested of the TC, because it had a unique
meta-recursion problem.  Under most circumstances, the problem of
constructing a ballot is, if not easy, then at least easier than solving
the problem being voted on.  For that particular case, ballot
construction reduced to the question being voted on, precisely because
Debian's usual failure mode^W^Wconsensus-building approach of let's do
everything!!1! effectively reduced to one of the other controversial
ballot options in the first place.

The primary proposal here for a cloture process also has an additional
misfeature not mentioned: a non-majority subset of the TC (3 members in
an 8-member TC) can indefinitely block a vote, which is itself a
procedural abuse (with extra bonus diffusion of responsibility), except
it seems to be by design.  In a situation in which there is no consensus
and the only solution is a vote, and the ballot itself cannot reach
consensus either (being precisely as contentious as the question at
hand), this cloture process allows the indefinite delay of the vote.
As such a delay may well align with one of the desired outcomes, that
process change itself seems rife with potential procedural abuses.

All that said, my argument here against adding a cloture process only
applies to the original proposal of a separate cloture vote with
supermajority and automatic inclusion of additional proposed options,
and not to the alternative proposal.

The alternative proposal (from AJ), modulo naming, effectively reduces
to you can only rank FD at the top or bottom, and you are encouraged to
vote FD at the top if you are not satisfied with the ballot.  That
actually sounds rather reasonable.  So does the cool-off-period part of
the original proposal; if FD wins, it makes sense to require Further
Discussion to actually take place.  Though I suspect that would
naturally happen anyway

Bug#795855: #636783 - New bugs for individual issues

[Josh Triplett]

On Mon, 17 Aug 2015 15:39:06 +0200 Didier 'OdyX' Raboud o...@debian.org wrote:
 - #795855
   Introduction of formal cloture vote for the TC
 
 - #795857
   TC chair appointment

Given context, I think these originally shotgunned proposals (especially
these two) need careful re-evaluation, to figure out how much actual
point they have and how much they're just a reflection of a past spite.

The cloture proposal honestly seems like a needless pile of additional
process.  Anyone can call for a vote at any time, and I don't think
that's a bug; if people agree that a vote is warranted, they can vote,
and if they don't, they can vote further discussion.  If even a simple
majority is opposed to holding a vote, they can all vote Further
Discussion.  Anyone else can *also* call for a vote at any time, if
they feel there's another issue to discuss.

So, I would suggest that the cloture proposal should be consigned to a
historical note along with the fit of pique it came from.

For 795857, the TC chair process, there is indeed a lack of documented
process for how and when the TC chair is determined; I think the
suggestion Bdale referenced makes sense, to re-evaluate this in light of
the new term limits:
On Tue, 18 Aug 2015 14:36:28 +0200 Bdale Garbee bd...@gag.com wrote:
 The suggestion someone made somewhere during this discussion that I
 liked the best was quite simple.  Every time there is a change in the
 membership of the TC, we should have a vote on who should serve as
 chair.  Given the term limits now in place, that would guarantee a
 fairly regular need to vote on the TC chair.

- Josh Triplett

Bug#741573: #741573: Menu Policy and Consensus

[Josh Triplett]

On Fri, 24 Jul 2015 16:20:52 +0200 Josselin Mouette j...@debian.org wrote:
 Sam Hartman hartm...@debian.org wrote: 
 That seems very unlikely to me.  Diversity is an important part of
 Debian.  I think it is likely that the TC is going to value the Debian
 Menu as long as Bill or someone else is going to work on it.  I would
 expect us to value the menu enough to enable those who want to
 contribute to it to do so.
 
 Given the state menu is in, reading this is… flabbergasting, to say the
 least. I would answer tons of things, but fortunately they have already
 been put together concisely: http://islinuxaboutchoice.com/ 
 
 I think that's consistent with the consensus proposal that you asked 
 us
 to consider in this bug.
 
 The consensus proposal was, in order to preserve some bits of Bill's
 ego, to let menu die slowly by stopping to require mandatory entries for
 a useless menu system that only a handful of obscure window managers are
 still able to display. Now that Bill has made very clear, by completely
 giving in to ridicule, that his ego should not be a problem, Charles is
 merely proposing to accelerate that process and avoid pain for everyone.

Josselin, do you really believe that an inflamatory message like this is
the right way to get your point across and get people to agree with you?

While I agree with the underlying arguments you're referring to, both
about choice and about the (lack of) value of the old menu system,
this kind of mail doesn't help anyone get past this issue, nor does it
come across as reasonable.  It's worth noting that the old menu system
provided a significant amount of value for many years, long before the
XDG menu existed.  That it no longer holds as much importants as it once
did is no reason to denigrate people involved with it.

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150727220416.GA3716@jtriplet-mobl1

Bug#741573: #741573: Menu Policy and Consensus

[Josh Triplett]

On Mon, 27 Jul 2015 15:05:03 -0700 Josh Triplett j...@joshtriplett.org wrote:
 On Fri, 24 Jul 2015 16:20:52 +0200 Josselin Mouette j...@debian.org wrote:
  Sam Hartman hartm...@debian.org wrote: 
  That seems very unlikely to me.  Diversity is an important part of
  Debian.  I think it is likely that the TC is going to value the 
  Debian
  Menu as long as Bill or someone else is going to work on it.  I 
  would
  expect us to value the menu enough to enable those who want to
  contribute to it to do so.
  
  Given the state menu is in, reading this is… flabbergasting, to say the
  least. I would answer tons of things, but fortunately they have already
  been put together concisely: http://islinuxaboutchoice.com/ 
  
  I think that's consistent with the consensus proposal that you 
  asked us
  to consider in this bug.
  
  The consensus proposal was, in order to preserve some bits of Bill's
  ego, to let menu die slowly by stopping to require mandatory entries for
  a useless menu system that only a handful of obscure window managers are
  still able to display. Now that Bill has made very clear, by completely
  giving in to ridicule, that his ego should not be a problem, Charles is
  merely proposing to accelerate that process and avoid pain for everyone.
 
 Josselin, do you really believe that an inflammatory message like this is
 the right way to get your point across and get people to agree with you?
 
 While I agree with the underlying arguments you're referring to, both
 about choice and about the (lack of) value of the old menu system,
 this kind of mail doesn't help anyone get past this issue, nor does it
 come across as reasonable.  It's worth noting that the old menu system
 provided a significant amount of value for many years, long before the
 XDG menu existed.  That it no longer holds as much importants as it once

s/importants/importance/; half-finished edit.

 did is no reason to denigrate people involved with it.
 
 - Josh Triplett
 
 


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150727224513.GA4663@jtriplet-mobl1

Bug#769972: Draft new member ballot

[Josh Triplett]

On Mon, 2 Mar 2015 16:02:19 -0800 Don Armstrong d...@debian.org wrote:
 The following is a draft of the ballot which will be used to recommend
 new CTTE members to the DPL.
 
 ===BEGIN
 
 The Technical Committee recommends that PERSON be appointment by the
 Debian Project Leader to the Technical Committee.
 
 A: Recommend to Appoint PERSON
 B: Further Discussion
 
 ===END

Wouldn't it make more sense to put all of the possible candidates on one
ballot?  If you put each on a separate ballot, what happens if there are
more winners than available committee slots, or if current committee
members want to express preferences?

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150303053629.GA23142@thin

Bug#762194: Initial draft of affirming transition to systemd as default for #762194

[Josh Triplett]

On Wed, 10 Dec 2014 11:10:10 -0800 Don Armstrong d...@debian.org wrote:
 I've attached below an initial draft of an option for #762194 for
 discussion.

A few comments below.

 ==BEGIN==
 
 In #762194, the Technical Committee was asked to use its power under
 §6.1.4 to override the decision of the init package maintainers to
 depend on systemd-sysv as the first alternative dependency, thus
 ensuring both new installs and upgrades use systemd by default.

This doesn't seem like an accurate description of #762194.  #762194 was
not specificlaly a request for the TC to override the maintainers of
init to change the alternative order.  The TC was more generally
debating whether the switch to systemd as the default included a switch
of existing systems to systemd, and if not, how to only switch for new
systems and not for upgrades (for which the TC solicited proposals).
Changing the init package dependencies (and changing debootstrap, d-i,
etc to install systemd-sysv for new installs) was one possible
implementation of the latter.

Here's an opening paragraph that seems clearer to me about the overall
purpose of the bug report and this statement:


In #762194, the Technical Committee considered whether upgrades of
existing systems should continue to switch to systemd by default, or
retain their init system (with only new installs getting systemd by
default).


 1. The CTTE determined in #727708 that systemd should be the default
init system in Debian. 
 
 2. In 87mwc9gfsw@xoog.err.no[1], the maintainers of the init
package announced their transition plan for migrating to systemd as
the default init system on both installs and new upgrades.

Possible addition, for clarity: The packages in jessie implement this
transition plan.

 ==OPTION A==
 
 Using its power under §6.1.5 to make statements:
 
 3. The CTTE affirms the decision of the init system package
maintainers to transition to systemd by default.

For clarity: to transition upgraded systems to systemd by default, not
just new installs.

 4. The CTTE appreciates the effort of Debian contributors to mitigate
any issues with the transition by:
 
a) Providing a fallback boot entry for sysvinit when systemd is the
default init in grub (#757298)
 
b) Developing a mechanism to warn on non-standard inittab
configurations which are unsupported in systemd.

I would change this from non-standard inittab configurations to uses
of /etc/inittab.  They're not non-standard; it's not incredibly common
to modify inittab to launch services or add consoles, but it's not by
any means non-standard.  I don't want to see anyone (such as a sysadmin
of a system with such a configuration) taking this TC statement as a
comment on the appropriateness of such inittab configuration.

Also, you might want to include a link here.  The mechanism was being
developed in a thread in #765803, but that's not the subject of that
bug, and that bug doesn't seem like the right place for it.  Thus, I've
re-posted the WIP code to a systemd bug, #761063.

c) Providing documentation on how to opt to remain with sysvinit on
both initial installs and upgrades.

Nitpick: on how to opt to remain with sysvinit on upgrades, or switch
to sysvinit for new installs.  (Also, how to opt to remain with seems
awkward; perhaps how to keep using?)

d) Numerous bug reports and fixes by contributors who have tested
the systemd migration in their configurations.

One potential addition:

5. The CTTE advises (without overriding any Debian contributor,
   maintainer, or team) that any such mitigations should be included in
   jessie, to ensure a smooth transition for Debian users.

(Since neither (a) nor (b) above has actually made it into jessie, or
unstable for that matter.)

That said, such advice may be unnecessary and superfluous; I'd hope
that's already the plan.

 1: https://lists.debian.org/87mwc9gfsw@xoog.err.no

I would suggest inlining this reference in the relevant paragraph, or at
least making it a footnote right after that paragraph, rather than an
endnote.

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141210204852.GA26649@thin

Bug#762194: Initial draft of affirming transition to systemd as default for #762194

[Josh Triplett]

On Wed, 10 Dec 2014 14:35:32 -0800 Don Armstrong d...@debian.org wrote:
 On Wed, 10 Dec 2014, Josh Triplett wrote:
  This doesn't seem like an accurate description of #762194. #762194 was
  not specificlaly a request for the TC to override the maintainers of
  init to change the alternative order.
 
 Well, more specifically, it was to override the transition plan (namely,
 to transition installs to systemd by default upon upgrade) which the
 maintainers of the init package had already proposed and implemented.

Fair enough.  I just didn't want the statement to reference any specific
technical proposal for doing so, especially when not advocating that
proposal (and not incorporating the additional changes that such a
proposal would require, such as to debootstrap or d-i).

 I've clarified this, and adopted the other changes:
 
 In #762194, the Technical Committee was asked to use its power under
 §6.1.4 to override the transition plan of the init package maintainers
 to have both new installs and upgrades use systemd by default.

I'd used the Technical Committee considered rather intentionally in
the wording I suggested, to avoid any of the controversy around was
asked from the previous last decision.  Not going to push for that,
just pointing it out as intentional.

 1. The CTTE determined in #727708 that systemd should be the default
init system in Debian. 
 
 2. In https://lists.debian.org/87mwc9gfsw@xoog.err.no, the
maintainers of the init package announced their transition plan for
migrating to systemd as the default init system on both installs
and new upgrades.
 
 3. The init package currently in jessie implements this transition.

While it's a bit of a nitpick, the transition plan involves more than
just the init package; it also includes the sysvinit packages (sysvinit
and sysvinit-core).  Perhaps s/package/packages/ (and
s/implements/implement/), since init packages logically includes
sysvinit, systemd, and other init system packages?

 ==OPTION A==
 
 Using its power under §6.1.5 to make statements:
 
 3. The CTTE affirms the decision of the init system package
maintainers to transition to systemd by default.

I'd suggested clarifying that this applies to both upgraded systems and
new installs.  Thoughts on that clarification?  (Given that this
additional TC deliberation and statement occurred specifically because
the original decision in #727708 did not specify upgrades versus new
installs, spelling that out explictly in the statement and not just in
the frontmatter seems preferable.)

 4. The CTTE appreciates the effort of Debian contributors to mitigate
any issues with the transition by:
 
a) Providing a fallback boot entry for sysvinit when systemd is the
default init in grub (#757298)
 
b) Developing a mechanism to warn on inittab configurations which
are unsupported in systemd. (#761063)
 
c) Providing documentation on how to remain with sysvinit on
upgrades and swithc to sysvinit upon installation.

Typo: s/swithc/switch/

d) Numerous bug reports and fixes by contributors who have tested
the systemd migration in their configurations.
 
 5. The CTTE advises (without overriding any Debian contributor,
maintainer, or team) that any such mitigations should be included
in jessie, to ensure a smooth transition for Debian users.

Thank you for adding this.

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141211000545.GA30153@thin

Bug#762194: Initial draft of affirming transition to systemd as default for #762194

[Josh Triplett]

Thanks for the updates; the current version in debian-ctte git (as of
commit e43bfb9cd1f6316ed01a58a4a248e82fc3825850) looks good to me.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141211021109.GA31561@thin

Thank you for your work, Ian

[Josh Triplett]

Ian Jackson wrote:
 I now hope to spend more of my free software time doing programming.
 dgit is at the top of my Debian queue, but some of my GNU and SGO
 projects could do with attention too.

Hi Ian,

I've been quite impressed with your technical contributions to Debian,
particularly dgit, and I'm glad to hear that you plan to continue that
work. I would have been quite sad if this had been a resignation from
the project rather than the TC.

For anyone who has not yet seen dgit, I recommend taking a look at it;
it's an impressive bit of wizardry that lets you pretend the entire
Debian repository all lives in git.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141119192100.GA4590@jtriplet-mobl1

Re: [CTTE #746578] libpam-systemd to switch alternate dependency ordering

[Josh Triplett]

Steve Langasek wrote:
 On Sun, Nov 16, 2014 at 04:52:37PM +0100, John Paul Adrian Glaubitz wrote:
  On Sat, Nov 15, 2014 at 04:16:28PM -0800, Don Armstrong wrote:
   5. We therefore overrule the decision of the maintainer of
  libpam-systemd binary package.  The Depends entry
 systemd-sysv | systemd-shim (= 8-2)
  should be replaced by
 systemd-shim (= 8-2) | systemd-sysv
 
  A decision which lead to another great Debian Developer leave the
  ship!
 
  Great Work!
 
 This demonization of the Technical Committee for doing their job under the
 constitution needs to stop.  If you don't like the way the TC is structured
 under the constitution, feel free to propose a GR to change that.  But if
 all you (and certain others across various Debian lists) are going to do is
 attack the members of the TC for making a decision they've been asked to in
 the way that they believe is technically correct, then I invite you to be
 the next Debian Developer to leave and I promise you I will not mourn your
 departure.

Questioning the actions of the TC is well within the right of any
developer/contributor.  Or do you believe the TC somehow above any
possible reproach?  The first resort of criticism should not be to
propose a GR to reform the TC, though it may well come to that
eventually.  But I would hope that a first step would be to ask the TC
to consider its actions and its consequences rather more carefully than
it has been before such measures become necessary.

(More constructive criticism would certainly carry more weight, but
given the current two-for-two pattern of decisions to departing
developers, I don't think anyone particularly wants to see the TC go for
the hat trick.)

 It's a shame that Tollef has decided to step down from the systemd
 maintenance team
 (http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2014-November/004563.html,
 which I believe is what you're referring to with your mail).  I have great
 respect for his technical abilities and consider him to have been a key
 voice of sanity throughout this painful process, and I hope that he doesn't
 actually view this TC override as an attack on the systemd maintainers.  I
 would point out that the majority of those who voted in favor of this latest
 resolution also voted for systemd as the default in jessie.  This is not an
 act of systemd haters, this is the TC providing technical guidance when
 asked to do so; and if the TC comes to a different conclusion than a
 maintainer who is acting in good faith, that is not an attack on that
 maintainer.

While it's certainly true that this particular TC decision seemed fairly
reasonable in isolation[1], it's also perfectly understandable that the
background or agreement on this decision would not be obvious to someone
who hasn't necessarily read every mail on -ctte and all the tech-ctte
bug reports.  In the absence of that, it seems quite understandable to
interpret this as yet another attempt by the TC to undermine systemd.

[1] (one of the reasons I took part in refining drafts of it, with
clarifying language explaining precisely why it would not affect the
ongoing transition, though in retrospect that language was clearly
insufficient)

I'd also disagree with when asked to do so, considering that the asker
was a TC member; in effect, the committee asked itself to decide, and
subsequently answered, just as with 762194.  And whether you consider it
an attack on a maintainer / maintenance team or not, it's unreasonable
to completely ignore the consequences of your decisions.

I share your sadness that this and many other actions has driven Tollef
away from the maintenance of a critical and difficult-to-maintain
package.  I do not, however, share your sanctimony.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141116212759.GA8535@thin

Bug#746578: libpam-systemd to flip dependencies - proposal

[Josh Triplett]

On Wed, 5 Nov 2014 11:49:45 + Ian Jackson ijack...@chiark.greenend.org.uk 
wrote:
 Ian Jackson writes (Bug#746578: libpam-systemd to flip dependencies - 
 proposal):
  So, I hereby formally propose the resolution text below.  I intend to
  call for votes some time tomorrow.
 
 Thanks again to Josh for all his careful and constructive
 interventions in the discussion.  I'm glad to see that he's now happy
 with this proposal.

This proposal doesn't seem to include the change you made in git commit
227f496617929c48bfd20a9c96eead8b91ee69b7 to fix a typo I reported in
item 4:
 4. In particular, on systems that already have systemd-sysv installed,
libpam-systemd will still not pull in systemd-shim, thus minimizing
the risk of breakage on systemd systems.  However, on systems that
intentionally do not have systemd installed, the installation of
libpam-systemd will then prefer to pull in systemd-shim and keep
the installed init system rather than switching to systemd-sysv.

In your mail with Message-ID
21590.30193.479905.710...@chiark.greenend.org.uk, you said:
Josh Triplett writes (Bug#746578: libpam-systemd to flip dependencies - 
proposal):
[...]
 s/intentionally do not have systemd/intentionally do not have systemd-sysv/

Fixed in git.  I hereby make that change to my formal proposal.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141105155158.GA13254@thin

Bug#746578: libpam-systemd to flip dependencies - proposal

[Josh Triplett]

On Wed, 05 Nov 2014 08:42:07 -0500 Sam Hartman hartm...@debian.org wrote:
 I don't think this matters for the vote, and apologies because there's
 probably a better place to send this advice.  I was thinking last night
 about the apt and debootstrap resolver issues and  was wondering whether
 the following solution might help.
 
 I realize the issue is minor and is more about minimizing packages
 installed than safety of the proposal.
 
 What if libpam-systemd depended on
 systemd-shim-nosysv|systemd-sysv|systemd-shim?
 
 Introduce a new package systemd-shim-nosysv in the systemd-shim package
 that depends on systemd-shim and conflicts with systemd-sysv.
 
 I have not tried this.  It might reduce the probability that
 systemd-shim gets uselessly installed.  however, I don't know whether it
 creates systems where systemd-sysv gets removed.

Seems like a great idea to me; we talked a bit about Conflicts in the
context of cgmanager, but this approach (with an artificial intermediate
package) makes much more sense.  I agree that it needs careful testing,
though; after Christian Seiler's testing of debootstrap and apt, I
really don't know how either would decide to resolve this.  Either or
both might well decide to choose the alternate dependency of the
essential init package rather than the alternate dependency of
libpam-systemd.

 Even if this does end up being a good idea, I don't think the TC
 resolution needs to change.  As I read it, the essential character of
 the resolution is that systemd-shim is preferred to systemd-sysv in
 libpam-systemd.  If we find better technical ways of doing that, more
 power to us all.  If there is a real disagreement about whether we're
 within the spirit of the TC resolution should it pass, we can ask the TC
 again either informally or formally.  I don't want to see us getting
 ultra-picky about the wording of resolutions to constrain or permit
 future innovation.

I agree; when I suggested clarifying in the TC decision that the Depends
shouldn't be hard-coded (what became clause 6 of the current proposal),
I didn't just have versioned dependency changes in mind, but also
package structural changes (on either systemd's or systemd-shim's part).
I think the suggestion you made above fits entirely within the spirit of
the TC resolution.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141105155932.GA13240@thin

Bug#746578: libpam-systemd to flip dependencies - proposal

[Josh Triplett]

On Tue, Nov 04, 2014 at 07:47:05AM +0100, Christian Seiler wrote:
 Am 02.11.2014 06:59, schrieb Josh Triplett:
  Apart from that, I would still request that someone with the ability to
  produce a modified local mirror test the two critical cases mentioned in
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#129 .  If those
  two cases work, then systemd systems should not end up with systemd-shim
  installed under normal circumstances, making breakage far less likely.
 
 debootstrap 1.0.64 on a current Jessie box with a locally modified
 and otherwise up-to-date (2014-11-04T05:00Z) mirror wants to pull in the
 following packages[1]:
 
[...snip list in favor of diff...]
 [1] debootstrap --print-debs --no-check-gpg \
   --include=libpam-systemd jessie $DIR $MIRROR
 
 PS: Diff of the stuff that is pulled in compared to the same command
 done in the current archive (after sorting the package list):
 @@ -7,6 +7,7 @@
  bash
  bsdmainutils
  bsdutils
 +cgmanager
  coreutils
  cpio
  cron
 @@ -57,6 +58,7 @@
  libcap2-bin
  libcap-ng0
  libc-bin
 +libcgmanager0
  libcomerr2
  libcryptsetup4
  libdb5.3
 @@ -70,6 +72,7 @@
  libgcc1
  libgcrypt20
  libgdbm3
 +libglib2.0-0
  libgmp10
  libgnutls-deb0-28
  libgnutls-openssl27
 @@ -94,6 +97,8 @@
  libnettle4
  libnewt0.52
  libnfnetlink0
 +libnih1
 +libnih-dbus1
  libp11-kit0
  libpam0g
  libpam-modules
 @@ -153,6 +158,7 @@
  sensible-utils
  startpar
  systemd
 +systemd-shim
  systemd-sysv
  sysvinit-utils
  sysv-rc

 I've also tried debootstrap 1.0.62 on a Fedora 19 box with the same
 mirror, with the same results.
 
 Note that systemd-shim together with cgmanager is pulled in.

Thank you very much for the careful testing and analysis!

This result concerns me greatly, and I think the technical committee
should take this into account when considering whether to flip the
dependencies of libpam-systemd around.

I find it odd that debootstrap produced this result, and I've filed a
bug on debootstrap about this, but in any case, with current
debootstrap, flipping the libpam-systemd dependencies around will result
in installing systemd-shim (but not any non-systemd init that needs it)
on systemd systems.  Given past bugs in both systemd-shim and cgmanager
that broke systemd, that seems less than ideal.  (Not utterly
unreasonable, but it introduces an entirely unnecessary additional
source of potential problems.)

This isn't a complete showstopper, since most of the time people seem to
debootstrap a standard system and then install additional packages.
However, it would affect a debootstrap with --include=task-desktop or
--include=gnome or similar.

Does anyone see an obvious way to structure the dependencies to avoid
this result and only install systemd-sysv?  If no way exists, it might
be worth making sure jessie's debootstrap gets fixed in time.

 My guess is that there's some greediness in the dependency resolver in
 debootstrap, and as long as there's no conflict, it won't try to follow
 other alternatives to see if the dependencies have already been met.
 
 Also note that neither --exclude=systemd-shim,cgmanager nor
 --exclude=systemd-shim seem to have no effect whatsoever on
 the list of packages. (Which is probably a bug in debootstrap, because
 it should at least warn you if it can't fulfill the specified --exclude,
 but also in this case it could actually exclude it...)

I've filed a bug on debootstrap for these two issues.

 I haven't tested the upgrade scenario.

I appreciate the test you already ran.  I'd love to see an upgrade test
as well (from a system with sysvinit installed), but this test already
revealed an issue.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141104160726.GA5844@thin

Bug#746578: libpam-systemd to flip dependencies - proposal

[Josh Triplett]

On Tue, 4 Nov 2014 17:54:53 + Ian Jackson ijack...@chiark.greenend.org.uk 
wrote:
 I've been reading the messages from Josh about cgmanager etc., and
[snip]

Actually, I'd like to completely withdraw my concerns there, in light of
some new information.

Quoting Serge Hallyn, maintainer of cgmanager:
 Currently the cgmanager sytemd unit is installed inactive, so by default
 it will not interfere with systemd.  The user needs to specifically
 enable it.

So, both systemd-shim and cgmanager seem entirely harmless on systemd
systems; the former will not run at all under systemd, and the latter
will not run by default under systemd.  Based on that, I no longer have
any concerns about flipping the dependencies around, even though doing
so will likely pull those two packages in on systemd systems per
Christian Seiler's detailed analysis.

I don't see any obvious further steps that need to occur other than
flipping the dependency around.  (It might be a good idea for the
libpam-systemd dependency to bump its versioned dependency on
systemd-shim to (= 8-4), but that's up to the libpam-systemd
maintainers.)

(This is still orthogonal to any discussions regarding switching on
upgrades, or regarding dependencies on systemd.)

- Josh Triplett

 Rationale (Constitution 6.1(5)):
 
 1. Currently libpam-systemd (which is pulled in by quite a few
dependency chains) Depends on `systemd-sysv | systemd-shim (= 8-2)'.
 
 2. The effect of this is that installing some packages which depend
(directly or indirectly) on libpam-systemd can cause a user's init
system to be switched to systemd, even on systems where a user has
deliberately chosen not to use the default init system, and even
when the switch is unnecessary.
 
 3. Swappping the order of these dependencies would avoid that and has
no harmful effect:
 
 4. In particular, on systems that already have systemd-sysv installed,
libpam-systemd will still not pull in systemd-shim, thus minimizing
the risk of breakage on systemd systems.  However, on systems that
intentionally do not have systemd installed, the installation of
libpam-systemd will then prefer to pull in systemd-shim and keep
the installed init system rather than switching to systemd-sysv.
 
 Decision (Constitution 6.1(4)):
 
 5. We therefore overrule the decision of the maintainer of
libpam-systemd binary package.  The Depends entry
   systemd-sysv | systemd-shim (= 8-2)
should be replaced by 
   systemd-shim (= 8-2) | systemd-sysv
 
 6. For the avoidance of doubt, we do not intend to set this specific
syntax in stone.  For example, if in future libpam-systemd needs to
depend on a later systemd-shim, or needs a versioned rather than
unversioned dependency on systemd-sysv, that is fine and would not
contradict our decision.
 
 Release (Constitution 6.1(5)):
 
 7. Our advice is that this change should be in jessie.  If necessary,
this view should be conveyed to the Release Team, after the change
is in unstable, by filing an unblock request in the usual way.
 
 ===
 
 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141105010724.GA11065@jtriplet-mobl1

Bug#746578: libpam-systemd to flip dependencies - proposal

[Josh Triplett]

On Sat, 1 Nov 2014 18:55:32 + Ian Jackson ijack...@chiark.greenend.org.uk 
wrote:
 Rationale (Constitution 6.1(5)):
 
 1. Currently libpam-systemd (which is pulled in by quite a few
dependency chains) Depends on `systemd-sysv | systemd-shim'.

Here, you give the simplified dependency without the version constraint,
while below you give the full Depends with version constraint.  Please
choose one or the other and use it consistently.

 2. The effect of this is that installing certain leaf packages which
depend on libpam-systemd can cause a user's init system to be
switched to systemd, even on systems where a user has deliberately
chosen not to use the default init system, and even when the switch
is unnecessary.

Nit: s/certain leaf//; the packages depending on libpam-systemd are not
actually leaf packages, and in fact various other packages depend on
them.

 3. Swappping the order of these dependencies would avoid that and has
no harmful effect.

I would suggest expanding on what no harmful effect means here: In
particular, on systems that already have systemd-sysv installed,
libpam-systemd will still not pull in systemd-shim, thus minimizing the
risk of breakage on systemd systems.  However, on systems that
intentionally do not have systemd installed, the installation of
libpam-systemd will then prefer to pull in systemd-shim and keep the
installed init system rather than switching to systemd-sysv.

Stating that explicitly in the rationale, to set expectations, seems
preferable to a vague no harmful effect that does not fully make sense
without reading the full history in the bug.  TC decisions should be
self-contained.

 Decision (Constitution 6.1(4)):
 
 4. We therefore overrule the decision of the maintainer of
libpam-systemd binary package.  The Depends entry
   systemd-sysv | systemd-shim (= 8-2)
should be replaced by 
   systemd-shim (= 8-2) | systemd-sysv

I think this decision needs to explicitly state that it does not require
any particular version numbers in the versioned dependencies, only the
specific order.  In particular, if libpam-systemd needs to increase its
versioned dependency on systemd-shim, or if it ever needs to add a
versioned dependency on systemd-sysv, that change should not violate
this TC decision.

 Release (Constitution  6.1(5)):
 
 5. We request that the Release Team allow this change to into jessie.
(This request should be conveyed to the Release Team, after the
change is in unstable, by filing an unblock request in the usual
way.)

Is this point necessary?  The freeze has not yet occurred, and I don't
see any obvious reason why the TC needs to explicitly direct the release
team here.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102054832.GA1167@thin

Bug#746578: libpam-systemd to flip dependencies - proposal

[Josh Triplett]

On Sat, 01 Nov 2014 12:26:14 -0700 Russ Allbery r...@debian.org wrote:
 So, this is also the last call for anyone to explain what harmful effect
 this could have if they think it would have a harmful effect.  My
 understanding is that all of the possible harmful effects have been fixed
 by various other changes.

systemd-shim 8-4 and newer no longer seem likely to produce harmful
effects, given that systemd-shim now depends on systemd rather than
shipping its own D-Bus policy, and that systemd-shim itself pointedly
does not launch on systemd systems.  Neither of those two properties
seems likely to change or break.

systemd-shim does depend on cgmanager, which seems more prone to
breakage, and in fact has a handful of open bugs on it.  cgmanager has
in the past broken on non-systemd systems.  I personally would like to
see a resolution of 755977 to deal with that.

Apart from that, I would still request that someone with the ability to
produce a modified local mirror test the two critical cases mentioned in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#129 .  If those
two cases work, then systemd systems should not end up with systemd-shim
installed under normal circumstances, making breakage far less likely.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102055908.GA1250@thin

Bug#746578: libpam-systemd to flip dependencies - proposal

[Josh Triplett]

On Sat, 1 Nov 2014 22:59:09 -0700 Josh Triplett j...@joshtriplett.org wrote:
 On Sat, 01 Nov 2014 12:26:14 -0700 Russ Allbery r...@debian.org wrote:
  So, this is also the last call for anyone to explain what harmful effect
  this could have if they think it would have a harmful effect.  My
  understanding is that all of the possible harmful effects have been fixed
  by various other changes.
 
 systemd-shim 8-4 and newer no longer seem likely to produce harmful
 effects, given that systemd-shim now depends on systemd rather than
 shipping its own D-Bus policy, and that systemd-shim itself pointedly
 does not launch on systemd systems.  Neither of those two properties
 seems likely to change or break.
 
 systemd-shim does depend on cgmanager, which seems more prone to
 breakage, and in fact has a handful of open bugs on it.  cgmanager has
 in the past broken on non-systemd systems.  I personally would like to
 see a resolution of 755977 to deal with that.

Important typo here: I meant cgmanager has in the past broken
systemd systems.  I had bugs like 761389 in mind there.  Hence 755977.

 Apart from that, I would still request that someone with the ability to
 produce a modified local mirror test the two critical cases mentioned in
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#129 .  If those
 two cases work, then systemd systems should not end up with systemd-shim
 installed under normal circumstances, making breakage far less likely.
 
 - Josh Triplett
 
 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102135634.GA1220@thin

Bug#746578: libpam-systemd to flip dependencies - proposal

[Josh Triplett]

On Sun, 2 Nov 2014 14:19:45 + Ian Jackson ijack...@chiark.greenend.org.uk 
wrote:
 Ian Jackson writes (Bug#746578: libpam-systemd to flip dependencies - 
 proposal):
  Here is my draft, just committed to git.  I'm open to suggestions for
  changes.  If we can't agree on the rationale I guess we could leave it
  out.
 
 Josh Triplette produced a helpful detailed review.  Here is the
 revised draft.

s/Triplette/Triplett/ :)

And thank you for the update.

One minor (but semantically significant) issue below, caused by a typo
in my original suggestion.

 Rationale (Constitution 6.1(5)):
 
 1. Currently libpam-systemd (which is pulled in by quite a few
dependency chains) Depends on `systemd-sysv | systemd-shim (= 8-2)'.
 
 2. The effect of this is that installing some packages which depend
(directly or indirectly) on libpam-systemd can cause a user's init
system to be switched to systemd, even on systems where a user has
deliberately chosen not to use the default init system, and even
when the switch is unnecessary.
 
 3. Swappping the order of these dependencies would avoid that and has
no harmful effect:
 
 4. In particular, on systems that already have systemd-sysv installed,
libpam-systemd will still not pull in systemd-shim, thus minimizing
the risk of breakage on systemd systems.  However, on systems that
intentionally do not have systemd installed, the installation of
libpam-systemd will then prefer to pull in systemd-shim and keep
the installed init system rather than switching to systemd-sysv.

s/intentionally do not have systemd/intentionally do not have systemd-sysv/

- Josh Triplett

 Decision (Constitution 6.1(4)):
 
 5. We therefore overrule the decision of the maintainer of
libpam-systemd binary package.  The Depends entry
   systemd-sysv | systemd-shim (= 8-2)
should be replaced by 
   systemd-shim (= 8-2) | systemd-sysv
 
 6. For the avoidance of doubt, we do not intend to set this specific
syntax in stone.  For example, if in future libpam-systemd needs to
depend on a later systemd-shim, or needs a versioned rather than
unversioned dependency on systemd-sysv, that is fine and would not
contradict our decision.
 
 Release (Constitution 6.1(5)):
 
 7. Our advice is that this change should be in jessie.  If necessary,
this view should be conveyed to the Release Team, after the change
is in unstable, by filing an unblock request in the usual way.
 
 


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102171044.GA6632@thin

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Josh Triplett]

On Sun, 19 Oct 2014 21:10:10 +1100 Stuart Prescott stu...@debian.org wrote:
  inittab_unusual_lines=$(
  grep '^[^#]' /etc/inittab |
  while read line ; do
  case $line in
  'id:2:initdefault:') ;;
 [...]
 
 I wonder if it would just be easier to look at the md5sum of the file and 
 compare it to the md5sum of the inittab that was shipped in various releases 
 -- that's a fairly idiomatic approach to dealing with config files that 
 changed.

I considered that approach, but that has two issues:

- It doesn't take into account inittab files that have a mixture of
  lines from the inittab files of multiple releases, all of which are
  supported.  The approach I used can include lines from any number of
  inittab variations.

- It can't check for generated lines for serial consoles or similar;
  finish-install can generate various additional inittab lines, which
  the check should include.

- It unnecessarily prompts even if only comments or whitespace have been
  edited.

  modified_initscripts=$(
  grep -lE '^/etc/init\.d/' /var/lib/dpkg/info/*.conffiles |
  xargs basename -s '.conffiles' |
  xargs dpkg -V |
  grep '^..5.. c /etc/init\.d/' |
  cut -d' ' -f3
  )
 
 For testing for modified init scripts, see also #760897 -- note that dpkg -V 
 requires jessie's dpkg (it is not available in wheezy). For some upgrades 
 between releases, we have advocated that people upgrade dpkg and apt first 
 and 
 then upgrade to the new release using the new versions of the tools but this 
 is far from idiot proof. There's a persistent expectation that just doing a 
 dist-upgrade should be enough and we see day-in-day-out that people do *not* 
 read the release notes.

Gah, I didn't realize that dpkg -V didn't exist in wheezy.  The package
with this check in its init script could have a Pre-Depends on jessie's
dpkg, which would solve the problem, but that may or may not be
desirable.

Based on the code from 760897, here's a version that should work with
wheezy's dpkg:

modified_initscripts=$(
dpkg-query --show -f'${Conffiles}' |
sed 's, /,\n/,g' |
sed -n '/^\/etc\/init\.d\//s/^\([^ ]*\) \(.*\)$/\2 \1/p' |
md5sum --quiet -c 2/dev/null |
cut -d: -f1
)

(Note that md5sum exits with non-zero if any of the checksums fail, but
since it isn't the last thing in the pipe, that doesn't actually matter
here.)

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141020031036.GA21941@thin

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Josh Triplett]

On Sat, 18 Oct 2014 20:59:54 -0700 Russ Allbery r...@debian.org wrote:
 When one of you has a chance, could you update this bug with the current
 thinking around how to handle upgrades, around the ordering of
 dependencies in libpam-systemd, and some of the other ideas (such as
 attempting to detect systems with /etc/inittab configuration or init
 scripts that don't follow systemd's assumptions) raised in those threads?

Not speaking for the systemd maintainers, but I just wrote and tested
the following shell code to detect sysvinit-specific configuration
(modified /etc/inittab or modified init scripts) that may indicate a
need for manual sysadmin action (and thus a prompt).  This needs a bit
of work to add potential serial console getty lines generated by
finish-install to the list of expected lines, as well as any other
lines generated by older versions of finish-install.

inittab_unusual_lines=$(
grep '^[^#]' /etc/inittab |
while read line ; do
case $line in
'id:2:initdefault:') ;;
'si::sysinit:/etc/init.d/rcS') ;;
'~~:S:wait:/sbin/sulogin') ;;
'l0:0:wait:/etc/init.d/rc 0') ;;
'l1:1:wait:/etc/init.d/rc 1') ;;
'l2:2:wait:/etc/init.d/rc 2') ;;
'l3:3:wait:/etc/init.d/rc 3') ;;
'l4:4:wait:/etc/init.d/rc 4') ;;
'l5:5:wait:/etc/init.d/rc 5') ;;
'l6:6:wait:/etc/init.d/rc 6') ;;
'z6:6:respawn:/sbin/sulogin') ;;
'ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now') ;;
'pf::powerwait:/etc/init.d/powerfail start') ;;
'pn::powerfailnow:/etc/init.d/powerfail now') ;;
'po::powerokwait:/etc/init.d/powerfail stop') ;;
'1:2345:respawn:/sbin/getty 38400 tty1') ;;
'2:23:respawn:/sbin/getty 38400 tty2') ;;
'3:23:respawn:/sbin/getty 38400 tty3') ;;
'4:23:respawn:/sbin/getty 38400 tty4') ;;
'5:23:respawn:/sbin/getty 38400 tty5') ;;
'6:23:respawn:/sbin/getty 38400 tty6') ;;
*) echo $line ;;
esac
done
)

modified_initscripts=$(
grep -lE '^/etc/init\.d/' /var/lib/dpkg/info/*.conffiles |
xargs basename -s '.conffiles' |
xargs dpkg -V |
grep '^..5.. c /etc/init\.d/' |
cut -d' ' -f3
)

if [ -n $inittab_unusual_lines ] || [ -n $modified_initscripts ]; then
# Substitute these variables into a debconf template and display it
cat EOF
/etc/inittab:
$inittab_unusual_lines

Modified init scripts:
$modified_initscripts
EOF
fi


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141019061025.GA2391@thin

Bug#765803: tech-ctte: Ask before changing init system when upgrading to jessie and Inform about init systems when installing jessie

[Josh Triplett]

On Sat, 18 Oct 2014 16:27:11 -0700 Cameron Norman camerontnor...@gmail.com 
wrote:
 On Sat, Oct 18, 2014 at 3:56 PM, Vincent Bernat ber...@debian.org wrote:
   ❦ 18 octobre 2014 13:32 +0200, Svante Signell svante.sign...@gmail.com :
 
  In summary, the CTTE is asked to make a decision on debconf warnings on:
  1) Changing init system on upgrades (including sid)
  2) Inform about alternate init systems for new installations
 
  2 is quite far-fetched. Why not a debconf warning to tell there are
  alternatives to nano? And another one to tell there are alternatives to
  bash? The installation will take several hours to let the user know
  there are alternatives to almost any component.
 
 Well one good reason is that when you install nano or bash,
 vi/vim/emacs and zsh/fish are not uninstalled.

And likewise, the systemd and sysvinit coexist on the same system; only
one of them can own /sbin/init, but you can have both on the same system
and boot either one via init=/lib/systemd/systemd or
init=/lib/sysvinit/init.

I don't think it makes sense to prompt on new installations of systemd.
I do think it makes sense to prompt on upgrades from sysvinit to systemd
if the user has any system configuration for sysvinit that will no
longer apply (modified /etc/inittab, modified /etc/init.d/*, etc).  I'd
prefer to avoid prompting on routine upgrades to systemd (without any
such configuration), but as a one-time migration, it wouldn't be *that*
awful.

I also think we need an entry in the release notes.

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141019050507.GA1086@thin

Bug#746578: Dealing with the conflicting dbus policies?

[Josh Triplett]

[Context: bug 765101 occurred because systemd-shim installs a dbus
policy that broke systemd.]

Given the increasing desire to install systemd-shim even on systems
moving to systemd, both to make init=/lib/sysvinit/init work and to
smooth the transition as part of 746578, I think we need a better
solution for this problem than just updating systemd-shim every time
systemd's dbus policy changes.

Simple solution: given that systemd-shim exists to help run systemd
services without systemd as PID 1, how about making systemd-shim depend
on systemd, which contains those services?  libpam-systemd (the normal
reason someone would want systemd-shim installed) already depends on
systemd, so this shouldn't change anything for potential users of
systemd-shim.  systemd-shim could then stop shipping a dbus policy at
all, and instead rely on the policy already shipped as part of systemd.

More elaborate solution, if the above is undesirable for some reason:
teach dbus to also reach policies from /run/dbus-1, and have
systemd-shim ship an init script that symlinks a policy file there iff
not booted via systemd.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141014050335.GA2124@thin

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Josh Triplett]

On Thu, 18 Sep 2014 17:14:01 -0700 Cameron Norman camerontnor...@gmail.com 
wrote:
 On Thu, Sep 18, 2014 at 2:10 PM, Josh Triplett j...@joshtriplett.org wrote:
  I'm pulling a quote from the bottom of Steve's mail to the top, to call
  attention to a new and critical point that I didn't see raised anywhere
  in the debian-devel discussion:
 
  On Thu, 18 Sep 2014 12:23:18 -0700 Steve Langasek vor...@debian.org wrote:
  If we decide that init *should* be automatically changed on upgrade, then
 
  (Which I'm assuming from your footnote [1] that you *are* in favor of?)
 
  the ordering of the dependencies on libpam-systemd is immaterial except in
  the specific case that someone has upgraded to (or newly installed) jessie,
  selected an init system other than the default, and subsequently installed 
  a
  desktop environment on a system that didn't initially have one.  In this
  case, installing the DE *definitely* should not override the user's
  explicit selection of init system.
 
  *This* is a point that I haven't seen raised in the entire previous
  discussion on debian-devel, and I think it's a completely valid point.
 
  Personally, in this case, I'd argue that the desirable dependency (which
  we can't easily express) would be sysvinit-core ? systemd-shim :
  systemd-sysv.
 
 To be more precise, it would be !systemd-sysv ? systemd-shim :
 systemd-sysv so that other alternate inits are treated equally.

No, that's not equivalent.  Having sysvinit-core installed, since it
only exists in jessie, indicates a system with sysvinit intentionally
and explicitly installed.

That said, as mentioned in my response to Steve's mail, approximating
the dependency with systemd-shim | systemd-sysv may suffice *if* it
doesn't break the new-install, upgrade, d-i, or debootstrap cases.

 One question: if `init` and `libpam-systemd` (with the inversed
 dependency) are installed simultaneously on a system with only
 sysvinit installed (i.e. Wheezy), apt would know that systemd-sysv is
 going to be installed (to satisfy init package's dependency) and would
 not install systemd-shim, correct?

That was one of the scenarios I mentioned in my response to Steve's
mail.  Someone should actually test that.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140919154600.GA21445@thin

Bug#762194: Automatic switch to systemd on wheezy-jessie upgrades

[Josh Triplett]

On Fri, 19 Sep 2014 13:44:43 +0100 Ian Jackson 
ijack...@chiark.greenend.org.uk wrote:
 Package: tech-ctte
 
 At the risk of generating confusion due to a duplication of threads:

On the contrary, thank you for moving this to a separate thread.

I would like to propose that, if the TC addresses this point at all, it
does so sequentially rather than in parallel.  I think it's worth
addressing 746578 first, which (assuming apt does the right thing in the
various install/upgrade scenarios) can be solved rather easily and
hopefully uncontroversially.

 It appears that the answer to #746578 (libpam-systemd dependency) does
 not depend on whether users upgrading should be switched to systemd by
 default.  The current state in jessie is that users are switched by
 default.  This is controversial.

I don't think this is as controversial as you think.  The current setup,
including the sysvinit transitional package and new essential init
package, was discussed and implemented by maintainers of sysvinit,
systemd, and upstart, and cleanly supports all three, while reflecting
the systemd default.

Furthermore, to quote Steve Langasek's mail:
 For the record, this is not my position.  I understand Russ's
 concerns, but I also think the grub transition is as much an example
 of the *problems* with such an approach as it is of the successes,
 because at the end of the day users are still left to manually switch
 away from grub1 - many of whom never have, and have wound up with more
 bugs over the long term as a result of using EOLed software.  We
 should take care that our users' upgrade experience is a good one, but
 there are downsides to a policy of never making a change on upgrade
 that we haven't 100% proven won't result in boot regressions.

Returning to your mail:
 There are also of course important practical problems with
 automatically switching.  There have been suggestions that these
 should be dealt with by automatically detecting problem cases.  But we
 do not yet have a coherent design for such an approach, let alone an
 implementation.  It is IMO too late in the jessie release cycle for us
 to be developing and introducing such a thing.  This is particularly
 true given that the details are likely to be contested.

I disagree with your characterization here.

The sysvinit transitional package provides one fallback, which allows
users to boot sysvinit via init=/lib/sysvinit/init.  Michael Biebl is
currently working on automatically adding GRUB menu options to boot
sysvinit, to make that even easier.

Apart from that, I expect the problematic cases to be quite obvious and
uncontested (other than by those who consider installing systemd at
all a problematic case).  And we can add additional checks quite
easily.  The most obvious cases are:

- /etc/inittab entries other than the default.
- Hand-edited /etc/init.d/* scripts from packages that will be
  overridden by .service files.

 The alternative would be:
 
 Users upgrading to jessie should, by default, be automatically
 switched from sysvinit to systemd, where feasible.
 
 A straightforward mechanism for avoiding the switch should be
 provided and documented.

I agree with documenting this: we should have a very clear statement in
the release notes documenting the new default init system, and stating
that anyone wishing to continue using sysvinit should install
sysvinit-core and systemd-shim.  We should also have a NEWS entry in an
appropriate package, for the benefit of users with apt-listchanges
installed.

I would also propose introducing a separate alternative requesting an
explicit unconditional prompt on upgrade; while not optimal, it would be
easy enough to add, and still preferable to having a different default
for upgrades than for new installs.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140919161608.GA21539@thin

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Josh Triplett]

I'd like to call attention to a few reasons why libpam-systemd should
continue to depend on systemd-sysv | systemd-shim.

First, see bugs like 761389 (and others on cgmanager and systemd-shim),
which are still popping up regularly.  While I acknowledge that people
are actively working on the shim stack, far fewer people work on or test
that stack (or have a reason to care about that stack) than on the
systemd stack, and that stack is continuously playing catch-up based on
new systemd development.  As a result, it will inevitably encounter more
issues than the systemd stack.  That's not an argument to drop that
stack, but it *is* an argument to not make it the default.  I don't
think it's reasonable to consider the shim stack a more natural change
from sysvinit; people argue for sysvinit based on legacy/maturity/etc,
but the shim stack introduces a significant amount of new machinery
with far *less* maturity, legacy, or testing than sysvinit *or* systemd.

Second, the technical committee *already* decided to make systemd the
default init system.  This seems like yet another attempt to seize an
opportunity to erode or undermine that decision.  (I anticipate many
more such attempts in the future.)  The technical committee decision did
not say default only for new installs, with upgrades using sysvinit,
for instance.

Third, there's already a proposal on -devel to detect potentially
problematic situations on upgrade (such as hand-edited /etc/init.d
scripts that would be superseded by un-edited .service files), and
prompt in that situation.  Such a prompt would be similar to the
existing prompts obtained when attempting to remove the package for the
running kernel; they're not the most elegant approach around, but they'd
address many of the concerns regarding more intricate sysvinit setups
that would need manual intervention for a smooth upgrade.  That would
then avoid introducing a prompt for *all* systems, even those that can
smoothly upgrade with no issues.

I would advocate for implementing the prompting proposal, and keeping
systemd-sysv as the first (preferred) alternative in libpam-systemd's
dependencies.

(Though, if a one-time unconditional prompt about upgrading to systemd
would serve as suitable warning, I'd advocate for that; however, somehow
I doubt that step would actually satisfy people calling for systemd's
head.)

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140918153431.GA14232@thin

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Josh Triplett]

On Thu, 18 Sep 2014 11:09:18 -0700 Russ Allbery r...@debian.org wrote:
 I conceptually dislike the user experience of switching init systems
 because the user upgraded some random package that, from their
 perspective, doesn't appear related to the init system.  I feel like
 switching init systems should be a more intentional action than that.
 There is a variety of local customization that is init-system-specific,
 and I'm dubious that we're going to be able to catch and warn about all of
 it.
 
 I've not made up my mind about the merits of switching init systems from
 sysvinit to systemd during a dist-upgrade, but if we do that, I think we
 should do it via some more deliberate and obvious method than pulling
 systemd-sysv in via the dependency tree of some random package.  The
 partial upgrade UX for that is really bad, IMO.

I agree completely that it doesn't make sense for the transition from
sysvinit to systemd to take place via libpam-systemd rather than via
some core package like init, not least of which because that would
mean systems with desktops or certain daemon packages installed would
get transitioned to systemd but other systems would not.

However, as far as I can tell, I think we've actually solved that
problem: wheezy systems with sysvinit installed will upgrade to the
transitional sysvinit package, which depends on init, which depends
on systemd-sysv | sysvinit-core | upstart.  Between that and init
being Essential: yes (which causes apt to try to install it on
all upgrades to jessie), that *should* cause a transition to
systemd-sysv.

Now, that's not quite optimal yet.  Michael Biebl is currently working
on a plan to have fallback boot options available in GRUB that will boot
to sysvinit when both are installed, and that would require having both
systemd-sysv and some sysvinit package (not clear which one) installed.
(This could support other bootloaders as well, and systems not
explicitly covered could still explicitly boot with
init=/lib/sysvinit/init on the kernel command line.)

Nonetheless, as far as I can tell, libpam-systemd is *not* the package
driving the systemd transition anymore.  Does that address your concern,
Russ?

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140918183435.GA2380@jtriplet-mobl1

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Josh Triplett]

On Thu, Sep 18, 2014 at 11:36:53AM -0700, Josh Triplett wrote:
 On Thu, 18 Sep 2014 11:09:18 -0700 Russ Allbery r...@debian.org wrote:
  I conceptually dislike the user experience of switching init systems
  because the user upgraded some random package that, from their
  perspective, doesn't appear related to the init system.  I feel like
  switching init systems should be a more intentional action than that.
  There is a variety of local customization that is init-system-specific,
  and I'm dubious that we're going to be able to catch and warn about all of
  it.
  
  I've not made up my mind about the merits of switching init systems from
  sysvinit to systemd during a dist-upgrade, but if we do that, I think we
  should do it via some more deliberate and obvious method than pulling
  systemd-sysv in via the dependency tree of some random package.  The
  partial upgrade UX for that is really bad, IMO.
 
 I agree completely that it doesn't make sense for the transition from
 sysvinit to systemd to take place via libpam-systemd rather than via
 some core package like init, not least of which because that would
 mean systems with desktops or certain daemon packages installed would
 get transitioned to systemd but other systems would not.
 
 However, as far as I can tell, I think we've actually solved that
 problem: wheezy systems with sysvinit installed will upgrade to the
 transitional sysvinit package, which depends on init, which depends
 on systemd-sysv | sysvinit-core | upstart.  Between that and init
 being Essential: yes (which causes apt to try to install it on
 all upgrades to jessie), that *should* cause a transition to
 systemd-sysv.
 
 Now, that's not quite optimal yet.  Michael Biebl is currently working
 on a plan to have fallback boot options available in GRUB that will boot
 to sysvinit when both are installed, and that would require having both
 systemd-sysv and some sysvinit package (not clear which one) installed.
 (This could support other bootloaders as well, and systems not
 explicitly covered could still explicitly boot with
 init=/lib/sysvinit/init on the kernel command line.)

Correction to this part of my mail: /lib/sysvinit/init is provided by
the sysvinit package, which will remain installed in an upgrade from
wheezy to jessie.  So, this already works, apart from the automatic
entries in the grub bootloader.  My apologies for suggesting that there
was more to do there in terms of package dependencies.

I just tested this by installing a wheezy minbase chroot with
debootstrap and upgrading it to jessie.  This installed systemd-sysv via
init, left sysvinit installed, and /lib/sysvinit/init existed for use
as a fallback init.  At no time was libpam-systemd installed.

 Nonetheless, as far as I can tell, libpam-systemd is *not* the package
 driving the systemd transition anymore.  Does that address your concern,
 Russ?
 
 - Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140918185054.GA9424@jtriplet-mobl1

Bug#746578: More systemd fallout :-/

[Josh Triplett]

On Wed, 17 Sep 2014 15:34:48 +0100 Ian Jackson 
ijack...@chiark.greenend.org.uk wrote:
 In #746578, a user requests that the dependency from libpam-systemd to
 systemd be changed from
systemd-sysv | systemd-shim
 to
systemd-shim | systemd-sysv
 
 The maintainers of libpam-systemd have rejected this change.  I would
 like the TC to set out the applicable principle(s), and overrule the
 maintainer in this case.
 
 
 As I understand it from reading the threads in the bug and on
 debian-devel, the effect of this would be:
 
  * New jessie installations would still get systemd.
 
  * squeeze-jessie upgrades which are not already using systemd would
 not be switched silently to systemd but would use systemd-shim
 instead.
 
  * Attempts to upgrade non-systemd systems in some other circumstances
would no longer switch silently to systemd.

The latter two points are not actually accurate.  I just tested this by
installing a wheezy minbase chroot using debootstrap and upgrading it
to jessie.

The list of packages installed as part of the wheezy minbase chroot:

apt base-files base-passwd bash bsdutils coreutils dash debconf
debconf-i18n debian-archive-keyring debianutils diffutils dpkg e2fslibs
e2fsprogs findutils gcc-4.7-base gnupg gpgv grep gzip hostname
initscripts insserv libacl1 libapt-pkg4.12 libattr1 libblkid1 libbz2-1.0
libc-bin libc6 libcomerr2 libdb5.1 libgcc1 liblocale-gettext-perl
liblzma5 libmount1 libncurses5 libpam-modules libpam-modules-bin
libpam-runtime libpam0g libreadline6 libselinux1 libsemanage-common
libsemanage1 libsepol1 libslang2 libss2 libstdc++6
libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl
libtinfo5 libusb-0.1-4 libustr-1.0-1 libuuid1 login lsb-base mawk mount
multiarch-support ncurses-base ncurses-bin passwd perl-base
readline-common sed sensible-utils sysv-rc sysvinit sysvinit-utils tar
tzdata util-linux xz-utils zlib1g

The upgrade:

/# apt-get --no-install-recommends dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  acl adduser dmsetup gcc-4.9-base init libaudit-common libaudit1 libcap2 
libcap2-bin libcryptsetup4 libdb5.3 libdbus-1-3 libdebconfclient0 
libdevmapper1.02.1 libgcrypt11 libgcrypt20 libgpg-error0 libkmod2 libncursesw5 
libpcre3 libprocps3 libsystemd-daemon0 libsystemd-journal0
  libsystemd-login0 libudev1 libwrap0 procps startpar systemd systemd-sysv udev
The following packages will be upgraded:
  apt base-files base-passwd bash bsdutils coreutils dash debconf debconf-i18n 
debian-archive-keyring debianutils diffutils dpkg e2fslibs e2fsprogs findutils 
gcc-4.7-base gnupg gpgv grep gzip hostname initscripts libacl1 libapt-pkg4.12 
libattr1 libblkid1 libbz2-1.0 libc-bin libc6
  libcomerr2 libgcc1 liblocale-gettext-perl libmount1 libncurses5 
libpam-modules libpam-modules-bin libpam-runtime libpam0g libreadline6 
libselinux1 libsemanage-common libsemanage1 libsepol1 libslang2 libss2 
libstdc++6 libtext-charwidth-perl libtext-iconv-perl libtinfo5
  libusb-0.1-4 libuuid1 login lsb-base mount multiarch-support ncurses-base 
ncurses-bin passwd perl-base readline-common sed sensible-utils sysv-rc 
sysvinit sysvinit-utils tar tzdata util-linux zlib1g
70 upgraded, 31 newly installed, 0 to remove and 0 not upgraded.
Need to get 33.7 MB of archives.
After this operation, 27.5 MB of additional disk space will be used.

(Including recommends would install a few additional packages, including
libpam-systemd because systemd Recommends it, but I used
--no-install-recommends to prove that libpam-systemd was *not* the
driver of the transition, nor was it involved in the upgrade.)

This transition is driven not by libpam-systemd as suggested in this bug
report, but by the sysvinit transitional package (which depends on
init) and by moving the Essential: yes bit from sysvinit to init.
Note that that transition was coordinated between the sysvinit, systemd,
and upstart maintainers, and that the init package also supports
sysvinit and upstart.

The sysvinit transitional package additionally provides sysvinit
itself via /lib/sysvinit/init, making it possible to boot sysvinit via
init=/lib/sysvinit/init even with systemd-sysv installed.  Michael Biebl
is working on automatically adding a GRUB menu entry to boot sysvinit if
present, which would make that even smoother.

Hope that helps,
Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140918185901.GA9801@jtriplet-mobl1

Bug#746578: Reasons to keep systemd-sysv as the first alternative

[Josh Triplett]

I'm pulling a quote from the bottom of Steve's mail to the top, to call
attention to a new and critical point that I didn't see raised anywhere
in the debian-devel discussion:

On Thu, 18 Sep 2014 12:23:18 -0700 Steve Langasek vor...@debian.org wrote:
 If we decide that init *should* be automatically changed on upgrade, then

(Which I'm assuming from your footnote [1] that you *are* in favor of?)

 the ordering of the dependencies on libpam-systemd is immaterial except in
 the specific case that someone has upgraded to (or newly installed) jessie,
 selected an init system other than the default, and subsequently installed a
 desktop environment on a system that didn't initially have one.  In this
 case, installing the DE *definitely* should not override the user's
 explicit selection of init system.

*This* is a point that I haven't seen raised in the entire previous
discussion on debian-devel, and I think it's a completely valid point.

Personally, in this case, I'd argue that the desirable dependency (which
we can't easily express) would be sysvinit-core ? systemd-shim :
systemd-sysv.  In other words, if the user has explicitly selected
sysvinit, as indicated by installing the sysvinit-core package that only
exists in jessie but not wheezy, then install systemd-shim to make that
work, otherwise use systemd-sysv.  That's not equivalent to either
libpam-systemd's current dependencies *or* your proposal to invert them.

If there's a way to express *that* dependency through the dependency
mechanism we currently have, I'd be entirely in favor of it; if a user
has explicitly selected sysvinit-core, as opposed to implicitly by
having sysvinit installed, then by all means they should end up with
sysvinit-core plus systemd-shim rather than systemd-sysv.

However, that said, if flipping the dependencies around (together with
the current sysvinit and init packages) would best approximate that,
without breaking any of the upgrade or new-install cases, then I'd be
happy to drop my objection to changing libpam-systemd's dependencies.

Specifically, are the following all true even with libpam-systemd's
dependencies inverted?  (Ideally it would help to test this via
debootstrap and apt.)

- Upgrades from wheezy to jessie, with or without a desktop environment
  installed, will transition from sysvinit to systemd-sysv, via the
  init/sysvinit packages (the latter providing /lib/sysvinit/init).

- New installs of jessie via d-i or debootstrap, with or without
  task-desktop or gnome, will install systemd-sysv.  (d-i is the
  important case, but I'm concerned about the deboostrap case because I
  don't know if apt would be smart enough to look at the *simultaneous*
  installation of init and libpam-systemd and favor init's preference of
  systemd-sysv over libpam-systemd's preference of systemd-shim.  I
  don't think d-i installs those simultaneously.)

- As you suggested below, installs of jessie that have explicitly
  switched to sysvinit (or upstart for that matter) and subsequently
  installed a package depending on libpam-systemd should install
  systemd-shim rather than systemd-sysv.

If all three of the above are true with init and sysvinit staying as
they are and libpam-systemd's dependencies switching around, then I
don't see any harm in switching the dependencies around, and I'll stop
advocating against that.  If any of the above would be broken with
libpam-systemd's dependencies inverted, then I'd advocate against
changing those dependencies for exactly that reason.

Ideally, I'd like to keep this part of the discussion (regarding Steve's
very reasonable point below that users who *explicitly* install
sysvinit-core in jessie should not be switched to systemd-sysv by
installing a desktop environment) separate from the question of whether
upgrades from wheezy to jessie should switch from sysvinit to
systemd-sysv (which as far as I can tell Steve is not objecting to, but
Ian is).

On Thu, 18 Sep 2014 12:23:18 -0700 Steve Langasek vor...@debian.org wrote:
 On Thu, Sep 18, 2014 at 11:36:54AM -0700, Josh Triplett wrote:
  On Thu, 18 Sep 2014 11:09:18 -0700 Russ Allbery r...@debian.org wrote:
   I conceptually dislike the user experience of switching init systems
   because the user upgraded some random package that, from their
   perspective, doesn't appear related to the init system.  I feel like
   switching init systems should be a more intentional action than that.
   There is a variety of local customization that is init-system-specific,
   and I'm dubious that we're going to be able to catch and warn about all of
   it.
 
   I've not made up my mind about the merits of switching init systems from
   sysvinit to systemd during a dist-upgrade, but if we do that, I think we
   should do it via some more deliberate and obvious method than pulling
   systemd-sysv in via the dependency tree of some random package.  The
   partial upgrade UX for that is really bad, IMO.
 
  I agree completely that it doesn't make

Bug#746715: the foreseeable outcome of the TC vote on init systems

[Josh Triplett]

 ballot to *not* make a statement at
this time:

- The Technical Committee believes that Debian's normal collaborative
  processes can successfully handle the ongoing maintenance and
  contribution of support for multiple init systems, and does not have a
  further statement to make about support for multiple init systems at
  this time.

(Wordsmithing welcome on all three of the above; they're intended as
roughly delineated positions, not rigid ones.)

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140522170138.GA7063@jtriplet-mobl1

Re: Bug#727708: init system coupling etc.

[Josh Triplett]

Ian Jackson wrote:
 Josselin Mouette writes (Bug#727708: init system coupling etc.):
  In all cases, it is unacceptable to put the burden of implementing
  logind on non-systemd systems on maintainers of packages that just need
  the logind interfaces. If it is not available, software such as gdm3
  will depend, directly or indirectly, on systemd as PID 1, and that will
  be all.
 
 Firstly, I think the scenario where the required integration work is
 not done is unlikely.  But in that scenario, we have two choices:
  (a) Effectively, drop all init systems other than systemd
  (b) Effectively, drop GNOME

In this hypothetical scenario, suggesting that as an either-or implies
that *not* dropping GNOME, and instead having it exist in the archive
and depend on systemd, would effectively be dropping support for all
init systems other than systemd.  For that to be true, it would imply
that GNOME has such a critical level of importance in the distribution
that just having GNOME depend on systemd would make non-systemd inits
unusable.  If that were true, then (b) would fairly obviously not be an
option.  (Or to say that the other way around: if dropping GNOME were an
option, then it must not be important enough for its dependency on
systemd to be a problem.)  And if it *isn't* true, then there's no
forced dichotomy here: GNOME can depend on systemd, non-systemd inits
can continue to work fine on systems not running GNOME, and the world
doesn't end.

(Given the hypothetical scenario above, I'm going to ignore the issue
that this is about much more than just GNOME, and that there's a pile of
other relevant software planning to depend on logind or systemd in the
future.  Nonetheless, it's worth poking at the logic in the
hypothetical, since it seems generally applicable to more cases.)

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140214151322.GA20325@leaf

Bug#727708: init system coupling etc.

[Josh Triplett]

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 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.
 
 Is this a suitable approach ?  If so then perhaps I should clarify my
 proposed wording.

This approach does solve one problem present in previous proposals, by
clarifying that a bug does not become any *more* severe just because it
involves init systems.  However, there are still two notable problems
this doesn't address.

First, on which init systems?.  Everything in Debian that provides
/sbin/init, no matter its capabilities or lack thereof?  Or some subset
of those implementations, in which case what are the selection criteria
for that subset?

Second, what makes init systems so wildly different from anything else
in Debian that the usual principles don't apply?  For any other package,
doesn't work when its dependencies are replaced is a wishlist bug.
Such bugs are often fixed, especially when a patch is supplied, but that
doesn't make them any more than wishlist, even though doesn't work
would be RC if the package's dependencies are satisfied.  That's true
even when the dependencies and their alternatives are packages that
can't coexist on the same running system.

As far as I can tell, the only difference is one of scale: systemd is
poised to provide functionality that far more packages want and might
benefit from depending on, and thus the fear that it will become
irreplaceable is higher.  Nonetheless, this still seems like something
that can be handled naturally.  People who want to support alternative
init systems can continue to do so; absolutely nothing is stopping them.
As long as that work remains tractable and people want to do it, it'll
find a way to happen; Debian developers are too good at cooperating with
each other for that not to work out.  If the work to support any
particular init system across all packages in the archive ever becomes
overwhelming and insurmountable, *that means something*.

It makes sense to ensure that developers or supporters of alternate init
systems can expect a reasonable reception for work they've done to make
packages work with their init system.  (I don't see any obvious reason
to expect that won't already happen, but it's certainly reasonable to
debate how best to achieve *that* goal.)  However, this proposal instead
suggests that if that work hasn't been done yet by anyone, something has
gone horribly wrong and must be fixed, rather than that a wishlist bug
exists and a patch would sure be nice.

Does a proposal phrasing exist that would satisfy the concerns
motivating this one, addressing the goal of supporting contribution of
support for alternate init systems, without making it a bug for the
maintainer of every package to do the work themselves?  Or is it the
intentional aim of this proposal to force package maintainers to do the
work of supporting all init systems themselves or face an RC bug?

(As an aside, while it wouldn't necessarily do everything you want out
of this proposal, I wouldn't be surprised if there's support from the TC
for a proposal of maintain sysvinit compatibility through jessie, and
support smooth upgrades, which ought to address the concerns that are
motivating your urgency in addressing this issue.  Passing such a
resolution would then allow for a more prolonged consideration of how to
handle things post-jessie, as well as consideration of whether existing
cooperative processes in Debian might be able to handle this isue given
the time.  Any particular reason *not* to do that?)

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140214154617.GB20652@leaf

Bug#727708: Call for votes on init system resolution

[Josh Triplett]

Keith Packard wrote:
 I believe that votes cast in the last ballot demonstrate a unanimous
 agreement that the answer for this package dependency question does not
 in any way depend on which init system is the default, and so this
 question could be resolved separately, with the question originally
 brought to the ctte resolved in another vote.

 I also think this vote can be represented by two (or maybe three) choices:

  1) The ctte takes no position on this issue at this time.

  2) Packages may depend on new init features, but those must be stated
 as virtual dependencies which can be satisfied by any init system

 and/or

  3) Packages must work with all init systems, potentially with reduced
 functionality

 Please read all of these as referring to more complete language already
 present in this bug report, and not as an attempt to rewrite the
 proposed options.

I assume option 1 is intended to represent the status quo, in which
there is no prohibition on depending directly on an init system?  That
seems like it should be stated explicitly, even if only in clarifying
text, since at first I wondered why there wasn't an equivalent of option
2 without the requirement for virtual dependencies, before realizing
that this is already permitted and the TC need only refrain from adding
restrictions.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140208001039.GA18104@jtriplet-mobl1

Bug#727708: Call for votes on init system resolution

[Josh Triplett]

Colin Watson wrote:
 Part of my concern with T is that it's so mealy-mouthed.  Where
 feasible, should, encouraged, etc.  By contrast, L is a bit
 heavy-handed.  It sounds like we may share some common goals between
 these, and maybe if we want those to stick properly we need to state
 those more explicitly rather than using proxies.  Do we agree, for
 instance, that we want it to be possible to run Debian's major desktop
 environments with any of the init systems with communities active in
 developing support for them?

Could you elaborate a bit about your objections to the wording of the T
option?  Is there some particular aspect of the wording of T that you
believe should be written more clearly, and does that represent a
syntactic or semantic cleanup?  And, more to the point, is there such a
cleanup that would affect your vote on T?

 On Thu, Feb 06, 2014 at 11:25:02PM -0800, Russ Allbery wrote:
  Neither T nor L actually imply what I think will happen in practice.  The
  T option gives explicit blessing to adding dependencies on non-default
  init systems, which I think is something that's only appropriate on a
  case-by-case basis for edge packages and cooperating package groups and
  isn't appropriate general advice.  It also doesn't distinguish between
  right now and after the jessie release, which I think is inappropriate.
 
 Agreed on both counts.  I understand why Ian (was it?) wanted to have
 the multiple init systems for the foreseeable future text, as a
 statement of general intent, and I don't disagree with that.  But I
 would prefer if the specifics (Therefore, for jessie and later
 releases:) were marked simply as Therefore, for jessie:.  That seems
 to dispose of part of your objection to L.

Given this statement, and Ian's followup objecting to that language,
might I suggest that there should be a version of the L rider that
includes the sunset provision limiting it to jessie, since there is
clearly support for such an option?

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140208002524.GA18348@jtriplet-mobl1

Bug#727708: call for votes on default Linux init system for jessie

[Josh Triplett]

Anthony Towns wrote:
 On 29 January 2014 21:13, Colin Watson cjwat...@debian.org wrote:
  On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
 Q2: Is it OK for packages to depend on a specific init system as
 pid 1 ?
Q2a: Is it OK for packages providing init systems to provide other
  APIs beyond just the minimum needed for starting/stopping services?
  We might disagree on the extent, perhaps, but I doubt anyone on the
  committee would vote against this in its general form;
 
 So looking at the votes today, I would have said that both Ian and
 Andi's original votes are against this (ranking the options which
 allow specifying a dependency on a specific init below further
 discussion), and probably Steve's does too, although I assume that's
 more an objection against the wording.
 
 At least, the impact seems like it is:
 
  - init systems can provide whatever extra APIs they like
  - other packages can only use extra APIs if they have a dependency on
 the providing package
  - packages may not depend on specific init systems
 
  * therefore packages cannot use the extra APIs

I agree with your conclusion on the practical effect here.

I'm also amused that exactly the same logic readily applies at the next
level down, to an init system making use of APIs and functionality that
Linux has and other systems do not.  In both cases, the question is the
same: least common denominator, or actually using available
functionality?

(To forestall the obvious objection: optional is the same as least
common denominator, in that it effectively prevents *relying* on that
functionality, and thus forces the creation of a
least-common-denominator fallback, which everything higher in the stack
must then cope with.)

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140206070218.GA829@leaf

Bug#727708: Depending on an init to be pid 1 == depending on a kernel to be running

[Josh Triplett]

Russ Allbery wrote:
 It's conceptually similar, but since kernels are tied directly to a
 Debian architecture, it's easier to handle the kernel case using our
 existing infrastructure.  There just isn't a binary package for that
 architecture if it doesn't work with that kernel, and most of the
 problematic cases, such as switching between init systems, don't apply
 in an analogous way.

There's a related case that seems exactly similar, though: some packages
need to depend on specific kernel features or versions, but that's not
currently representable in the packaging system.  You can't currently
depend on a kernel with CONFIG_FOO available (or with the module
installed), or a kernel with the foo syscall, or kernel version 
3.10.  That restriction against depending on a kernel applies for a
variety of reasons: to support locally compiled and installed kernels,
to allow for multiple installed kernels chosen at boot time, and to cope
with having a kernel installed without having booted into it (perhaps
because you haven't rebooted yet).

While we don't need to support locally compiled and installed init
systems (anyone doing that can use equivs or package it properly), we
may potentially want to support multiple installed inits in parallel, we
may want to support selecting them at boot time, and we *definitely*
have to handle the case where you've installed a new init but not yet
rebooted into it.

It'd be nice to have a solution to both of those problems.  Perhaps we
could (start the multi-release process to) augment dpkg to support
special dependencies such as kernels and init systems, for instance.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140203220257.GA14066@jtriplet-mobl1

Bug#727708: call for votes on default Linux init system for jessie

[Josh Triplett]

Steve Langasek wrote:
 On Tue, Jan 28, 2014 at 09:23:11AM -0800, Keith Packard wrote:
  Bdale Garbee bd...@gag.com writes:
 
   Thus, I believe the only acceptable option for Q2 from among your set is
   requiring a specific init is permitted even if it is not the default
   one.  But I would prefer to vote a ballot that doesn't mention
   dependencies at all.
 
  I agree with this; I don't think we should try to force developers into
  significant work to satisfy an init system constraint as that may
  prevent or delay important fixes and improvements from entering the
  repository.
 
  Of course, nothing would prevent someone else from fixing these kinds of
  bugs and having those fixes get merged into the package, potentially
  invoking §6.1.4 to have the tech-ctte resolve any conflict as needed.
  However, I'd anticipate that most package developers would readily
  accept fixes that made their packages work for more people.
 
 I'd like to believe this; however, the fact that bug #726763 is still open
 leads me to fear otherwise.

I don't see any counterexamples in 726763 to the statement that nothing
would prevent someone else from fixing these kinds of bugs and having
those fixes get merged into the package, or to the statement that most
package developers would readily accept fixes that made their packages
work for more people.  Fixing 726763 just needs a Depends from the
GNOME packages to reflect their dependency on logind and the suspend
inhibit mechanism, which as stated in the bug log won't happen until the
resolution of 727708.  Meanwhile, installing either systemd-sysv or
systemd-shim (or having systemd installed and booting with
init=/bin/systemd) fixes the issue reported in 726763.

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140201201507.GA13442@leaf

Bug#727708: multiple init systems - formal resolution proposal

[Josh Triplett]

 sysvinit scripts
 indefinitely.

Likewise.

  As Philipp Kern points out in
  41b26b373019ab39ebff223603a08...@hub.kern.lc, this leaves us with the
  very real possibility that we will wind up with mutually incompatible
  sets of packages in the archive for jessie that are no longer
  coinstallable, not because the packages themselves have conflicting
  functionality, but because they've taken sides - intentionally or
  unintentionally - on the init system question.  If we don't think such
  fragmentation of the Debian archive is an acceptable outcome (and I for
  one don't see any reason it should be), then we should say as much in
  our resolution.  The committee has a duty to provide strong technical
  guidance to the project, not just to get involved after something has
  gone off the rails.

[As an aside, I want to respond to this point: pretty much by
definition, if the technical committee has to consider an issue at all,
something has already gone off the rails.  The technical committee is
not a steering committee; it's a mediation process for when normal
collaboration has not succeeded.]

 If you want to explicitly say that packages are required to support the
 default init system, then you should propose language.  That's not what
 the loose coupling option says.  The loose coupling option says that all
 packages must support *all* init systems, with some possible degredation
 of operation.  I believe that effectively locks us into supporting
 sysvinit scripts forever, since no alternative universal common
 denominator seems to be emerging.

Furthermore, I'd argue that the loose coupling rider as currently
proposed makes it more *difficult* for alternatives to systemd to
effectively compete with systemd, precisely because of the requirement
to support *all* init systems.

Suppose upstart added compatibility for several of systemd's most
popular daemon interfaces.  L, as written, would prohibit daemons from
depending on either systemd or a sufficiently new version of upstart,
because that makes the daemon depend on specific providers of PID 1.
Thus, as Russ pointed out, loose coupling effectively forces the
lowest common denominator of not requiring anything sysvinit lacks.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140201211229.GA13727@leaf

Re: Processed: block 726763 with 727708

[Josh Triplett]

On Sat, Feb 01, 2014 at 03:24:47PM -0500, Steve Langasek wrote:
 On Sat, Feb 01, 2014 at 08:09:24PM +, Debian Bug Tracking System wrote:
  Processing commands for cont...@bugs.debian.org:
 
   block 726763 with 727708
 
 On whose behalf are you setting such a block?  You are not listed as a
 maintainer of gnome-settings-daemon, and even those members of the TC who
 have been arguing against codifying a requirement to support multiple init
 systems in the TC resolution have said they want maintainers to work
 together to provide reasonable support for init systems other than the
 default.
 
 The above 'block' would be tantamount to an assertion that you have no
 intention of accepting patches from maintainers of non-default init systems
 to provide compatibility unless forced to do so by the TC; but as you're not
 a maintainer of the package, that doesn't seem relevant here.

I'm going to attempt to ignore the confrontational tone of your mail, on
the assumption that you can't possibly be proposing that nobody other
than a package maintainer should ever do bug triage for fear of stepping
on the maintainer's toes.  I've done such triage on numerous bugs in the
past, including adjustment of blocks, severity (including RC
severities), and so on, always on the assumption that the maintainer
will agree with the change; that assumption generally holds true.  Bug
metadata is trivially changed or reverted, and we already have informal
policies regarding such metadata, notably the general presumption that
the maintainer can always change it if they disagree, and that they have
the final say.  Thus, implicit in the block added above is the
assumption that the maintainer can trivially change it if they disagree;
if they did so, I certainly would not change it back and play BTS
tennis.

The block added above simply reflects the many comments from GNOME folks
(and systemd folks for that matter) saying that they're waiting for the
fallout to clear before making any drastic changes.  Furthermore, it
reflects the reality of the current situation: you explicitly stated in
the bug log of 726763 that systemd-shim was not ready to serve as an
alternative to GNOME (though with different assumptions about how to
resolve that), and you furthermore objected to the suggestion of
resolving the situation by adding a recommends on systemd-sysv.  Thus, I
don't see any obvious action the gnome-settings-daemon maintainer could
take at this point to resolve 726763 without drawing ire.

I would furthermore object strongly to your claim that the block is an
assertion that you [sic] have no intention of accepting patches from
maintainers of non-default init systems to provide compatibility unless
forced to do so by the TC.  Metadata is a dynamic thing reflecting the
current reality as it stands, and there are no such patches currently on
offer.  Patches that the maintainers find acceptable would certainly be
cause to remove the block (and add the patch tag).

See also Russ's very clear response, which I agree with wholeheartedly;
thank you, Russ.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140201214218.GA13928@leaf

Bug#727708: multiple init systems - formal resolution proposal

[Josh Triplett]

On Sat, Feb 01, 2014 at 01:21:19PM -0800, Russ Allbery wrote:
 Josh Triplett j...@joshtriplett.org writes:
 
  It should be completely trivial to introduce a virtual
  org-freedesktop-login1 package (modulo any complexities introduced by
  interface versioning for new methods added to that interface).  However,
  it also seems pointless until there's a prospective provider of that
  interface.  Do you have a package ready to provide that interface such
  that GNOME can depend on it?  I've seen no signs that the GNOME
  maintainers would refuse to allow alternative providers of those
  interfaces once they exist, just refusals to do any work in that
  direction until those alternatives *do* exist, which seems entirely
  reasonable.
 
 Note that I don't think it makes sense for Steve to work on such a package
 right now for exactly the same reason that I don't think it makes sense to
 start adding virtual packages right now, or figuring out the dependency
 structure in GNOME for non-systemd logind right now.  Personally, I
 wouldn't want to work on any of those things until some of the currently
 extremely large probability space collapses.

I agree entirely; I was simply indicating (in other parts of my previous
mail) that in the absence of a package ready to provide
org-freedesktop-login1, a dependency (indirect or direct) on systemd's
logind or org-freedesktop-login1 would reduce to a dependency on systemd
as PID 1.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140201214942.GB13928@leaf

Re: Processed: block 726763 with 727708

[Josh Triplett]

On Sat, Feb 01, 2014 at 03:24:54PM -0800, Steve Langasek wrote:
 On Sat, Feb 01, 2014 at 01:42:23PM -0800, Josh Triplett wrote:
  The block added above simply reflects the many comments from GNOME folks
  (and systemd folks for that matter) saying that they're waiting for the
  fallout to clear before making any drastic changes.  Furthermore, it
  reflects the reality of the current situation: you explicitly stated in
  the bug log of 726763 that systemd-shim was not ready to serve as an
  alternative to GNOME (though with different assumptions about how to
  resolve that), and you furthermore objected to the suggestion of
  resolving the situation by adding a recommends on systemd-sysv.  Thus, I
  don't see any obvious action the gnome-settings-daemon maintainer could
  take at this point to resolve 726763 without drawing ire.
 
 Ok, it seems that wherever I sent my previous note about how I thought this
 should be fixed, it didn't actually manage to go to the bug log.  Sorry
 about that.

Thanks for that clarification.  That would explain why I hadn't seen
that mail when I reviewed the full bug log.

 While I think the Depends: systemd should be dropped (via a split of the
 systemd package), that's not required for fixing the present problem.  That
 can be addressed by having gnome-settings-daemon Depends: systemd,
 systemd-shim | systemd-sysv.

While that would DTRT for users with systemd-sysv installed, it will not
work for a majority of current systemd users in Debian, who use systemd
via just the systemd package and having init=/bin/systemd on the
kernel command line.  For such users, this change would attempt to
install systemd-shim, which should not happen on systems running
systemd.

Do you have a suggestion for how to solve that, given the constraints
of:

- not having systemd-shim conflict with systemd (since you've stated
  that you'd like to avoid that),
- not causing breakage in the systemd package, and
- not requiring systemd users to install systemd-sysv?

I can think of a few, but none that would be particularly simple to
implement or apply.

Adding systemd-shim as an alternative to the current dependency on
systemd could partially work, with the caveat that users who have
systemd installed but are not currently booted into it would experience
breakage.

As an aside, what is the list of interfaces systemd-shim provides?  I
previously had the impression that systemd-shim just provided the
systemd DBus interfaces that logind depended on, but did not provide
org.freedesktop.login1 directly, counting on a forked logind to provide
that on top of systemd-shim.  Are you saying systemd-shim provides
logind's interface directly, and thus satisfies GNOME's full dependency
needs already?

I'd also point out that there's no reason, other than the common issue
of init=/bin/systemd systems (which applies to both orderings) and the
current cloud of uncertainty surrounding init systems in Debian, that
that dependency couldn't also be written systemd-sysv | systemd-shim.
Bug 727708 blocks one of the two alternatives but not the other, and I
see no reason not to consider both alternatives equally.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140202000255.GA16178@leaf

Bug#727708: multiple init systems - formal resolution proposal

[Josh Triplett]

On Sat, Feb 01, 2014 at 05:23:11PM -0500, Steve Langasek wrote:
 On Sat, Feb 01, 2014 at 01:12:34PM -0800, Josh Triplett wrote:
  In particular, in the case of GNOME, I don't see any package in the
  archive yet for a fork of logind that depends on systemd-shim instead of
  systemd, so there's no alternative available for GNOME to depend on.
 
 There is no fork of logind *required* today.

Only because the same cloud of uncertainty is blocking an update of
systemd past version 204, and even then only assuming you pull in logind
from the systemd package and use it with systemd-shim, which leads to
yet another lovely pile of controversy.

 This bug would be fixed, today, by a dependency on 'systemd-shim |
 systemd-sysv', which is what I asked for in the bug.

Which would break systems that have the systemd package installed and in
use via init=/bin/systemd.  (In the interests of keeping discussion in
one place rather than two, let's keep the discussion of solutions to
that particular bug in that bug, rather than here, please.)

  There's little point to adding a virtual package with no providers yet,
  because until the cloud of uncertainty leading to 727708 gets resolved,
  a (direct or indirect) dependency on systemd-sysv | empty-alternative
  seems unlikely to fly, and seems likely to lead to more rants against
  the GNOME maintainers for depending on systemd.
 
 Of course, because that would be forcing a non-default init system (forcing
 installation of systemd-sysv before the decision has been taken on the
 default init system).  As things stand today, a dependency on systemd-shim |
 systemd-sysv would fix the bug for our users without forcing a change of
 init system on upgrade.

Leaving the aforementioned breakage aside, there's also the issue that
other parts of GNOME will need more than just what systemd-shim
currently provides, and having inconsistent dependencies in the GNOME
packages makes no sense.  Furthermore, having systemd-shim installed
will make upgrades to a post-727708 future version of Debian with
systemd installed that much more painful, since there's no
straightforward way for package dependencies to switch from
systemd-shim to systemd|systemd-shim correctly.

Seems preferable to see the outcome of 727708 first, the result of which
might well lead the GNOME packages to depend on systemd-sysv |
systemd-shim instead, or perhaps on systemd-sysv |
org-freedesktop-login1 if that proves logistically easier.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140202001518.GB16178@leaf

Bug#727708: init system resolution - revised proposal

[Josh Triplett]

Don Armstrong wrote:
 On Thu, 30 Jan 2014, Josh Triplett wrote:
  Ian Jackson wrote:
  Software outside of an init system's implementation may not require
  a specific init system to be pid 1, although degraded operation is
  tolerable.
 
  For instance, consider a gnome-session-systemd package which uses
  systemd user sessions, provided in parallel with a compatibility
  package that does not. Or, consider the systemd-shim package. As
  written, this clause would prohibit such alternative packages, even
  though *collectively* the packages satisfy this requirement.

 Using software instead of packages sidesteps this problem, I think,
 since that avoids the technical details of how such compatibility is
 implemented.

How confident are you that the entire technical committee and the
community of people filing bugs in the future will share your
interpretation of that statement in the resolution, versus the
interpretation that would result in an automatic RC bug on *any* package
that Depends: systemd-sysv (or logical equivalent), even if an
alternative package exists?  And to ask the reverse question: given your
interpretation above, how averse are you to making some kind of
clarification along the lines of what you said above official rather
than unofficial?  I'd hate to see people arguing over this ruling later
if a one-sentence clarification could make it completely unambiguous.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140131082735.GA30160@leaf

Bug#727708: init system resolution - revised proposal

[Josh Triplett]

A couple of comments inline below.

Ian Jackson wrote:
 == dependencies rider version T (Tight coupling) ==
 
This decision is limited to selecting a default initsystem; we
continue to welcome contributions of support for all init systems.
 
Software may require a specific init system to be pid 1.
 
However, where feasible, software should interoperate with
all init systems; maintainers are encouraged to accept
technically sound patches to enable interoperation, even if it
results in degraded operation while running under the init system
the patch enables interoperation with.
 
 == dependencies rider version L (Loose coupling) ==
 
This decision is limited to selecting a default initsystem; we
continue to welcome contributions of support for all init systems.
 
Software outside of an init system's implementation may not require
a specific init system to be pid 1, although degraded operation is
tolerable.

There is an issue with this wording, which I don't think is intended.
Sometimes, the easiest way to maintain support for multiple init systems
involves having a family of packages, each of which enables support for
one init system or family of init systems.  For instance, consider a
gnome-session-systemd package which uses systemd user sessions, provided
in parallel with a compatibility package that does not.  Or, consider
the systemd-shim package.  As written, this clause would prohibit such
alternative packages, even though *collectively* the packages satisfy
this requirement.  I would suggest adding language like the following,
optionally with the following [non-binding] example:

   Packages which form part of a set of alternatives integrating with
   different init systems need not individually run on other init
   systems, as long as the packages collectively meet the requirements
   of this section.  [ For example, a package using systemd to launch a
   user session, provided as an alternative to a package that runs on
   sysvinit, need not itself run on sysvinit. ]

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140131000141.GA29048@leaf

Bug#728486: Draft of Resolution for 728486 (lvm/systemd compatibility)

[Josh Triplett]

Don Armstrong wrote:
 Below is the current draft of a resolution to resolve 728486. I have one
 current comment in the draft which I would like clarified. [CTTE
 members: please comment/suggest change.] I also expect to change the
 reference to the patch to a newly updated patch with the changes
 suggested in
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728486#183.
 
 ==BEGIN DRAFT==
 
 When systemd is in operation in conjunction with lvm and lvmetad is
 not in use, lvchange -aay must be called after udevadm --settle which
 is provided by systemd-udev-settle.service, and before (and after)
 encrypted devices are configured (cryptsetup.target).
 
 ==COMMENT==
 Is there any case where udevadm --settle would be required after the
 encrypted devices are configured? Does cryptsetup.target ensure that
 udev has triggered the appropriate rules for the newly configured
 encrypted devices?
 ==END COMMENT==
 
 The patch prepared by Michael Stapelberg stapelb...@debian.org in
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728486#163 installs
 the two systemd unit files necessary to properly configure lvm devices
 when systemd is running, and additionally configures systemd-tmpfiles.d to
 create the lockfile directories required by systemd.
 
 Therefore, the CTTE:
 
 A. Overides the objection of the maintainer of lvm (Bastian Blank
 wa...@debian.org) to this patch, and directs the maintainer to
 accept this patch or alternatively, authorizes an NMU to implement
 this patch.

One minor nit for this draft: the ruling should not exclude the
possibility of enhancing LVM in the future to handle dynamically added
devices *without* using systemd-udev-settle.service.  (That may occur by
using lvmetad in cases where it works, for instance.)

Suggested change, if a TC member agrees: leave all the existing content,
but add an additional paragraph right before the Therefore saying:
Nothing in this ruling should be taken to block future changes to LVM
to support dynamic discovery of devices without the need for udevadm
--settle or systemd-udev-settle.service; in the event such changes fully
obsolete the patch in question, the patch may be dropped.

Does that sound reasonable?

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129221933.GA16719@jtriplet-mobl1

Bug#727708: TC endorsement, political aspects

[Josh Triplett]

 certainly wouldn't expect the upstart
  developers to go out of their way to support systems not running
  upstart, beyond that needed to allow smooth transitions from another
  init system to upstart.

   In this context the systemd project's apparent lack of
   prioritisation of the legitimate divergence of wishes and goals
   on the part of its downstreams is especially worrying.

Speaking as someone who has followed the development of systemd since it
was created, the systemd maintainers have taken quite a bit of care to
work with downstreams who have varying needs.  The components of systemd
have accomodated areas of distribution divergence and aided in smooth
transitions, even in areas of gratuitous divergence (e.g. distributions
using different configuration files for the same thing).  systemd has
tried to adopt the best technical solutions from a variety of
distributions; for instance, using /etc/hostname from Debian and
changing Fedora and other distributions to match.  (Lest you think
systemd will make Debian always conform to Fedora rather than the other
way around...)

In short, systemd has put a great deal of prioritization on the needs of
its downstreams.  And if Debian becomes one of those downstreams, I
fully expect to see Debian's needs taken into account.  In particular,
if Debian has a solution that works *better* than one in systemd (rather
than just working *differently*), I'd fully expect to see systemd
adapting to work with that solution, and potentially helping Debian
spread that solution to other distributions as well.

That said, systemd is *also* working to harmonize areas of gratuitous
divergence in distributions, where there's no reason other than
hysterical rasins to continue being different.  And that's a feature,
not a bug.  In those areas, Debian ought to take part in the discussions
about which approach to adopt, and then support a careful transition to
that approach.  It's reasonable to expect Debian, systemd, and other
distributions to cooperate with each other; it's not reasonable to
expect systemd to do all the adapting, which is what the text you posted
seems to assume.


Now, with that spirit of future cooperation in mind, I would suggest
something more like the following, if and only if this is deemed
important enough to form part of the systemd resolution and the systemd
proponents are in favor of it as well.  Also note the use of
[non-binding advice brackets].

[
- The Technical Committee encourages Debian maintainers of systemd and
  other packages to work with their upstreams, downstreams, and
  counterparts in other distributions, to achieve the best possible
  integration between systemd and Debian.  In particular, we would
  recommend avoiding gratuitous divergences from existing Debian
  behavior and expectations, as well as avoiding gratuitous divergences
  from upstream systemd behavior.  In cases where the those two differ,
  we encourage collaboration to determine the best possible solution for
  both upstream and Debian, to provide for smooth transitions for any
  resulting changes, and to accommodate users of other init systems
  where reasonably possible.
]

Personally, I believe this falls in the area of package maintainers
should already know this and do this anyway.  However, if there's a
consensus that the TC resolution needs to say something about this, and
in particular if none of the TC members favoring systemd would object to
voting for a resolution that included it, then I'd suggest something
closer to the above as a clear statement of *cooperation*, rather than a
demand that systemd conform to Debian (discounting the possibility that
Debian could ever change to adopt what might be better alternatives).

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140120174045.GA5829@jtriplet-mobl1

Bug#728486: Current patch for resolving lvm/systemd compatibility

[Josh Triplett]

Bastian Blank wrote:
On Sat, Jan 18, 2014 at 11:33:32PM +0100, Michael Biebl wrote:
 Wants= will make sure the systemd-udev-settle.service is started
 dynamically and After= ensures the correct ordering.
 
 It only makes sure that systemd-udev-settle.service was started
 somewhere _before_.  It does however not make sure it is called again
 for the second round or third round.

It doesn't matter if you run udevadm settle once, twice, or twelve
times; it still won't guarantee that more devices won't show up later.
Dynamic hardware detection does not work the way you wish it did, and
udevadm settle will not change that; it will only slow down the boot
process for everyone.  Calling it once for all broken services is quite
enough.

On a different note, this patch also has a serious limitation: it
doesn't automatically disable itself when use_lvmetad=1, which seems
like the right way to handle dynamic hardware detection in any
environment that lvmetad can handle (anything other than a multi-host
cluster, as far as I can tell).

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140119192453.GA1572@leaf

Bug#727708: init system discussion status

[Josh Triplett]

On Sat, Jan 04, 2014 at 06:14:30PM +, Ian Jackson wrote:
 (Josh, is there some reason why you replied to the TC list directly
 rather than the bug report ?  You should send your messages to the bug
 so they are filed, displayed and archived there.  Thanks.)

I don't subscribe to debian-ctte@; I read it via the list archives.
I've been replying using the Reply to: links at the bottom of mails,
and then manually copying and quoting the responses.  Those links reply
to debian-ctte@lists.debian.org, so unless I manually edit the
destination (which I've done in a few cases where the destination was a
bug report), it ends up going to the list.

It'd be nice if those links paid attention to the
To/Cc/Reply-To/Mail-Followup-To addresses, and otherwise acted like
hitting the reply key in a mail client.  I'd also add my voice to the
set of people who have requested mbox archives in the past.

 Josh Triplett writes (Re: Bug#727708: init system discussion status):
  Clint Adams wrote:
   As loath as I am to participate in this discussion, I have to ask
   if your intent is to suddenly outlaw all the packages which depend
   on runit.
 
 Thanks for your intervention which is helpful.
 
  I think it'd be appropriate to allow dependencies on runit (or another
  package that contains an implementation of /sbin/init), as long as
  either the depending package doesn't depend on having /sbin/init be that
  init (which holds true for runit),
 
 Right.
 
  *or* if an alternative package exists to integrate with the default
  init system.  For instance, git-daemon-run versus
  git-daemon-sysvinit versus a hypothetical git-daemon-systemd,
 
 Personally I think this is a pretty nasty way for the git packages to
 have done things, although I understand why.  But, regardless, I think
 it's certainly fine from the init system compatibility point of view.

I'm not a big fan of its long insistence on runit (git-daemon-sysvinit
came much later), but I actually rather like the idea of putting init
scripts and systemdiwde configuration in a separate package from
daemons.  In the case of git, it makes sense because the daemon lives in
the git package, which shouldn't start a daemon.  More generally,
though, I wish more packages were split the way Apache is, with one
package containing the daemon and all supporting files, and the other
package containing the configuration for a systemwide daemon.  I've
found that particularly useful on many occasions.

  ...  (Note that the latter would work better if upstart stopped
  conflicting with sysvinit, similar to how systemd can be installed
  without being init.)
 
 There does seem to need to be some work there.

As I understand it, conflicting with sysvinit and not offering a package
that can be installed in parallel with it was an intentional decision on
the upstart maintainers' parts.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140104194552.GA6867@leaf

Bug#727708: init system discussion status

[Josh Triplett]

On Sat, Jan 04, 2014 at 11:27:26AM -0800, Steve Langasek wrote:
 On Sat, Jan 04, 2014 at 06:14:30PM +, Ian Jackson wrote:
   ...  (Note that the latter would work better if upstart stopped
   conflicting with sysvinit, similar to how systemd can be installed
   without being init.)
 
  There does seem to need to be some work there.
 
 That has already been resolved in unstable, with the split of sysvinit
 contents out of the Essential: yes sysvinit into sysvinit-core.  (A
 necessary precondition for switching to either systemd-sysv or upstart for
 jessie.)

That solves one part of the problem, in that the package upstart
conflicts with is no longer Essential; however, that still doesn't allow
installing upstart without making it /sbin/init.  A split similar to the
one between systemd and systemd-sysv would make that possible, allowing
users to try out upstart by setting init= on the kernel command line,
and allowing packages to use upstart for purposes other than running it
as init (for instance, for graphical session startup).

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140104194822.GB6867@leaf

Re: Bug#727708: init system discussion status

[Josh Triplett]

Russ Allbery wrote:
 Oh, hm, actually... the systemd notification protocol allows you to tell
 systemd what the actual PID of the process to manage is, using the MAINPID
 variable.  So I think you actually could write a wrapper that starts the
 actual daemon as a child, waits for it to stop using waitpid, sends it
 SIGCONT, tells systemd that it's ready along with passing MAINPID pointing
 to the child process, and then exits.

 I'd have to try that to see if it would actually work, but I bet it would,
 and it would be a fairly easy program to write since you can just use
 libsystemd-daemon and don't have to write any of the socket code.

 There are probably still some gotchas to sort out, such as signals
 received before the child process signals readiness and how to handle
 them, but I think that's all doable.

It's an interesting idea as an exercise, but I can't think of a single
advantage to using this mechanism in practice, compared to just fixing
the daemon to do systemd-compatible startup notification (or better yet
socket activation).

But as long as we're trying to come up with ways to make an unmodified
upstart-compatible daemon work that you'd never actually use in
production, what about an LD_PRELOAD library that hooks the raise
function, passes through all calls other than SIGSTOP, and changes the
first call to raise(SIGSTOP) into a call to sd_notify?  Still seems far
uglier than just patching the daemon, but as an exercise that actually
does seem cleaner than introducing a second process.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140105070553.GA15198@leaf

Re: Bug#727708: init system discussion status

[Josh Triplett]

Clint Adams wrote:
On Fri, Jan 03, 2014 at 10:02:01AM -0800, Nikolaus Rath wrote:
 As said elsewhere, I think there should be a paragraph about packages
 that depend on a specific init system for reasons other than service
 startup, e.g.
 
 4. The above criterium also extends to dependencies that are not related
to service startup. In jessie, no package may depend on a single
initsystem other than sysvinit. After jessie, no package may depend
on a single init system other than the default init.
 
 or alternatively   
 
 4. Packages may, however, depend on a specific init system (which may
not be the default init) for features that are not related to daemon
startup. Such packages will only be installable on systems running a
non-default init, but are permitted in the archive.

 As loath as I am to participate in this discussion, I have to ask
 if your intent is to suddenly outlaw all the packages which depend
 on runit.

I think it'd be appropriate to allow dependencies on runit (or another
package that contains an implementation of /sbin/init), as long as
either the depending package doesn't depend on having /sbin/init be that
init (which holds true for runit), *or* if an alternative package exists
to integrate with the default init system.  For instance, git-daemon-run
versus git-daemon-sysvinit versus a hypothetical git-daemon-systemd, or
a future gnome-session-systemd or gnome-session-upstart package (for
whichever init system isn't the default).  (Note that the latter would
work better if upstart stopped conflicting with sysvinit, similar to how
systemd can be installed without being init.)

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140104033210.GA17653@leaf

Re: Bug#727708: init system other points, and conclusion

[Josh Triplett]

On Wed, Jan 01, 2014 at 08:09:56AM -0500, Chris Knadle wrote:
 On Tuesday, December 31, 2013 20:12:20 Josh Triplett wrote:
  Steve Langasek wrote:
  On Tue, Dec 31, 2013 at 09:13:52PM +0100, Josselin Mouette wrote:
   So unless the TC wants to remove a great number of packages from the
   archive, you need to take into account the fact that some voluntary
   manpower is required to implement your decision.
   
   I think the current Debian GNOME team has a not-undeserved reputation for
   being obstructionist with respect to bugfixes that require divergence from
   upstream's stated direction.  If the team demonstrated they were open to
   contributions of the kind you described, volunteers to do the work would
   not be hard to come by.
  
  That's an impressively high amount of doublespeak packed into a single
  paragraph, particularly the words bugfixes, volunteers, and
  contributions.  At a minimum, I think you're overstating the situation
  by refusing to acknowledge that the GNOME team does not consider the
  changes forced upon them to be bugfixes. 
 
 Responding specifically to this:
 
  You (and other members of the TC) disliked GNOME's requirement of
  NetworkManager, for reasons I still have yet to see explained coherently
  anywhere.  You forced the GNOME team to remove it.  I certainly hope
  you find volunteers willing to do that kind of work increasingly hard
  to come by.
 
 Re: dependency removal -- sort of.  The reasoning is explained  for the most 
 part in the tech-ctte decision for #681834. [1]  But just to fully make this 
 clear I'll also provide a brief summary of what I think happened at the time.
[...snip explanation...]

I appreciate the explanation, and I'm familiar with the contents of the
decision.  I simply see nothing there that should have motivated a
tech-ctte decision, rather than simply a couple of bug reports against
network-manager and an added Conflicts/Breaks or two.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140101164713.GA13257@leaf

Re: Bug#727708: init system other points, and conclusion

[Josh Triplett]

On Wed, Jan 01, 2014 at 03:40:17PM -0500, Chris Knadle wrote:
 On Wednesday, January 01, 2014 08:47:13 Josh Triplett wrote:
  On Wed, Jan 01, 2014 at 08:09:56AM -0500, Chris Knadle wrote:
   On Tuesday, December 31, 2013 20:12:20 Josh Triplett wrote:
Steve Langasek wrote:
On Tue, Dec 31, 2013 at 09:13:52PM +0100, Josselin Mouette wrote:
 So unless the TC wants to remove a great number of packages from the
 archive, you need to take into account the fact that some voluntary
 manpower is required to implement your decision.
 
 I think the current Debian GNOME team has a not-undeserved reputation
 for
 being obstructionist with respect to bugfixes that require divergence
 from
 upstream's stated direction.  If the team demonstrated they were open
 to
 contributions of the kind you described, volunteers to do the work
 would
 not be hard to come by.

That's an impressively high amount of doublespeak packed into a single
paragraph, particularly the words bugfixes, volunteers, and
contributions.  At a minimum, I think you're overstating the situation
by refusing to acknowledge that the GNOME team does not consider the
changes forced upon them to be bugfixes.
   
   Responding specifically to this:
You (and other members of the TC) disliked GNOME's requirement of
NetworkManager, for reasons I still have yet to see explained coherently
anywhere.  You forced the GNOME team to remove it.  I certainly hope
you find volunteers willing to do that kind of work increasingly hard
to come by.
   
   Re: dependency removal -- sort of.  The reasoning is explained  for the
   most part in the tech-ctte decision for #681834. [1]  But just to fully
   make this clear I'll also provide a brief summary of what I think
   happened at the time.
  [...snip explanation...]
  
  I appreciate the explanation, and I'm familiar with the contents of the
  decision.  I simply see nothing there that should have motivated a
  tech-ctte decision, rather than simply a couple of bug reports against
  network-manager and an added Conflicts/Breaks or two.
 
 In other words, what you're saying is that not only is there no problem that 
 the GNOME maintainers mandated that I get NetworkManager, which I personally 
 most certainly don't want, but that the tech-ctte should have made a ruling 
 that would have forced users to uninstall wicd too.  :-/  Not cool.

It's fairly clear that NetworkManager and wicd conflict, so having a
proper Conflicts or Breaks so that apt can inform you of that seems
preferable to having the two packages both installed and trying to
manage networking.  Even in the current situation, that conflict ought
to exist, since the two packages can't coexist and shouldn't be expected
to.

As for GNOME requiring NetworkManager, GNOME also requires mutter these
days as part of gnome-shell, and doesn't work with other window
managers, and I don't expect GNOME to support configurations attempting
to replace its window manager either.  Likewise you can't replace
dconf/gsettings, or gnome-panel.  With enough patching you probably
could, just as with the current pile of patches it manages to run
without NetworkManager, but that doesn't mean it *should*.  In other
news, http://islinuxaboutchoice.com/ .  I expect to see GNOME making
quite a few more upstream requirements in the future as it continues to
try to make more aspects of system configuration Just Work, and I'd very
much like to see those requirements properly represented in Debian as
dependencies.

But no, I don't think the tech-ctte should have made a ruling that would
have forced users to unstall wicd; I think they simply should have
declined to rule on the situation.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140101212804.GA16748@leaf

Re: Bug#727708: init system other points, and conclusion

[Josh Triplett]

On Wed, Jan 01, 2014 at 09:37:24PM +, Ian Jackson wrote:
 Josh Triplett writes (Re: Bug#727708: init system other points, and 
 conclusion):
  On Wed, Jan 01, 2014 at 03:40:17PM -0500, Chris Knadle wrote:
   In other words, what you're saying is that not only [something
   about NetworkManager]
  
  It's fairly clear that NetworkManager [something something]
 
 Can I suggest that raking over these old coals isn't really helping ?
 
 Anything that could have convinced any of the participants in that
 dispute has already been said.  I doubt anyone is going to change
 their mind now.
 
 For the same reason bringing this dispute up as an example is probably
 not that helpful either.

This particular branch of the discussion doesn't seem particularly
helpful, no, and I hadn't planned to continue it further.

I do think NM serves as a useful cautionary tale here, to the extent
that both it and systemd/logind represent ongoing sources of costly
divergence for GNOME packaging, and I think folks who just see the
original tech-ctte decision there may be under the mistaken impression
that that work was over and done with with just a change to package
metadata.  However, I don't think this branch of the discussion in
particular is relevant to that point, and I'm happy to drop it.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140101215122.GA17157@leaf

Re: Bug#727708: init system thoughts

[Josh Triplett]

On Mon, Dec 30, 2013 at 10:37:42PM -0800, Steve Langasek wrote:
 On Mon, Dec 30, 2013 at 09:58:07PM -0800, Josh Triplett wrote:
   But in the real world, we have a lot of services that we just want to 
   start
   in runlevel 2 and be able to trust that the network and disk are sorted.
   This is the classic guarantee that sysvinit gave us pre-udev, but it's
   fallen apart since then because a fast system can get all the way through
   rcS before the kernel has even managed to enumerate all the network 
   devices.
 
  udev didn't break this assumption; this assumption became unreasonable
  once people started wanting to dynamically change networks.  If you have
  a service that can't cope with network interfaces showing up later on,
  that same service won't cope with connecting to a new wireless network,
  or plugging or unplugging an Ethernet cable.
 
  I've run into this *exact* problem with upstart, and I found it entirely
  untenable.
 
 You've also said that your experience with upstart was on ChromeOS, not
 Ubuntu.  I'm happy that ChromeOS is using upstart, but it shares almost none
 of the more recent event policy that would be common to Ubuntu and Debian
 and is not a useful proxy for understanding how upstart would behave in
 Debian.

I've also used upstart on Ubuntu (on servers, in particular), though not
extensively (or perhaps I should say as little as possible).  And I've
used upstart in Debian, which I'd expect to be an exemplar of how
upstart behaves in general.  (I will certainly admit to not having used
it in Debian *recently*, but I've used it in Ubuntu recently.  I found
it no less painful.)  More importantly, I've studied the upstream
behavior of upstart quite extensively; I wouldn't by any means consider
myself an expert, but I've read the upstart documentation in detail
multiple times.  If you have additional information about ways in which
Ubuntu has made upstart behave differently than the upstream upstart
behavior that would apply to this particular case, I'd be interested in
hearing about them.

Also, I'd consider it a deficiency in upstart if understanding upstart
in one distribution does not necessarily provide universal information
about how it behaves everywhere.  systemd makes a point of addressing
that problem: if you understand how systemd works in one distribution,
you understand how it works, period, modulo any (hopefully temporary)
distribution packaging bugs.

 Not that I'm sure what you mean by this exact problem, anyway.  The fact
 that services that don't deal with network changes are problematic?  Yes,
 ok, but I don't see how that has anything to do with using upstart or not,
 and is not what I was trying to say upstart solved.  The more common case,
 where you need to start a service that listens on a socket, is that it is
 running on a server and you need to make sure the static network - which,
 once configured, will not change for the lifetime of the server - is up
 before trying to start the service.

That's the exact case I was talking about, modulo the non-existence of a
concept like the static network.  I've worked with upstart jobs for
services that don't understand how to deal with a changing network, and
found it a sufficiently lost cause that it was easier to fix the service
(or rather, to select a better implementation of the service).  The
events associated with network devices did not seem particularly clear,
nor did the execution model of upstart with respect to one upstart job
and multiple relevant events.

 Again, we're all agreed that the server
 shouldn't be coded that way, but that doesn't change the fact that there are
 a lot of these daemons out there in packages with init scripts, and we want
 them to be as reliable as possible.

The right way to make them as reliable as possible is to treat them as
buggy and fix them.  Anything else is a hack to work around buggy
daemons.  I'd argue that any facility in either upstart or systemd (or
sysvinit for that matter) that waits around for the network should be
exclusively for use by the system administrator as a dependency of local
services, and that Debian should not ship any daemon depending on such a
facility; that's the kind of thing I'd like to see making its way into
Policy.  Since such a service would be buggy today with sysvinit, I
don't think such a Policy change would depend on any particular init
system.

  In any case, systemd does indeed support this case; simply make your
  service depend on network-online.target, which will block for a
  reasonable amount of time to see if a network interface comes online,
  and eventually time out if that doesn't occur.  This will actually work
  even if your primary network is a wireless network managed by
  NetworkManager, and even if that network doesn't actually work until the
  user has logged in, assuming your service is not actually in the
  dependency path of the user logging in.
 
 And what makes this work in the case where you *aren't

Bug#727708: systemd-shim uploaded to NEW

[Josh Triplett]

Steve Langasek wrote:
 Looking more closely, I find that one of the conflicting files is a conffile
 (/etc/dbus-1/system.d/org.freedesktop.systemd1.conf).  diversions and
 conffiles still don't mix, AFAIK (and according to current policy).  So that
 seems to still leave us without a proper solution that doesn't involve
 splitting the systemd binary package.

Files in /etc/dbus-1/system.d/ need not have names that match the
interface they control; see, for instance, gdm.conf or
nm-dhcp-client.conf.  Why not simply install a systemd-shim.conf with
the contents you need?  To the best of my knowledge, I see nothing in
org.freedesktop.systemd1.conf that should interfere with you.

(That said, personally I'd prefer to see systemd-shim continue to
conflict with systemd, and work with a hypothetical
forked-systemd-logind package instead, which would also conflict with
systemd.  That would then, for instance, unblock systemd's ability to
upgrade past version 204.)

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131231091630.GA23112@leaf

Re: Bug#727708: init system other points, and conclusion

[Josh Triplett]

Steve Langasek wrote:
On Tue, Dec 31, 2013 at 09:13:52PM +0100, Josselin Mouette wrote:
 So unless the TC wants to remove a great number of packages from the
 archive, you need to take into account the fact that some voluntary
 manpower is required to implement your decision.
 
 I think the current Debian GNOME team has a not-undeserved reputation for
 being obstructionist with respect to bugfixes that require divergence from
 upstream's stated direction.  If the team demonstrated they were open to
 contributions of the kind you described, volunteers to do the work would not
 be hard to come by.

That's an impressively high amount of doublespeak packed into a single
paragraph, particularly the words bugfixes, volunteers, and
contributions.  At a minimum, I think you're overstating the situation
by refusing to acknowledge that the GNOME team does not consider the
changes forced upon them to be bugfixes.  You (and other members of
the TC) disliked GNOME's requirement of NetworkManager, for reasons I
still have yet to see explained coherently anywhere.  You forced the
GNOME team to remove it.  I certainly hope you find volunteers willing
to do that kind of work increasingly hard to come by.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140101041218.GA5505@leaf

Re: Bug#727708: systemd-shim uploaded to NEW

[Josh Triplett]

Tollef Fog Heen wrote:
 Initially, by waiting for the ctte to come to a conclusion.  If that is
 that systemd should be the default init system I think we should solve
 the problem by not solving it.  If the decision is that another init
 system should be solved, I'm probably going to solve it by removing the
 init functionality from the systemd package at which point the bug
 solves itself, AIUI.

Speaking as a happy user of the Debian systemd packages: please don't.
Having seen Russ Albery's mail regarding transition plans
(https://lists.debian.org/debian-ctte/2013/12/msg00258.html), which I'd
agree with wholeheartedly, I hope that even if Debian makes the mistake
of choosing upstart as a default, that the systemd packages remain
viable.  (After all, Debian needs at least one sane init system. ;) )

Regardless of the outcome of the tech-ctte's decision, I would happily
serve as an early-warning system for any breakage that occurs in other
packages when used without upstart, and I'll happily volunteer to help
maintain the systemd packages on an ongoing basis if that would help.

Thanks again for all your work on systemd.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131230211144.GA32283@leaf

Re: Bug#727708: init system thoughts

[Josh Triplett]

Colin Watson wrote:
 (Now, I've been working with Upstart's model for years, and it's now a
 pretty fundamental way of how I think of system operation; so if people
 who are new to *both* models rather than partisans of one side or the
 other consistently tell me that the systemd model is easier to grasp,
 then I'll listen.)

I'd like to respond to this point, since I have a clear memory of
dealing with both upstart's model and systemd's model for the first
time.  I also work professionally with a system (ChromeOS) that uses
upstart, and I've dealt with systemd quite a bit as well.  For the sake
of full disclosure, my position is that I'd prefer systemd over upstart;
I'd be OK with upstart if and only if systemd remained a viable
alternative (in other words, packages maintaining both upstart jobs and
systemd units but not necessarily maintaining init scripts seems pretty
reasonable).  So, at this point I'm squarely in the systemd camp, but
not for any particular reasons of partisanship; I simply find the
technology and model better.

I started out dealing with the sysvinit model, pre-startpar; I dealt
quite frequently with the magic ordering numbers (S20, K80, etc).  My
first exposure to dependencies was through startpar and LSB, and they
made sense, though I was never a fan of the magic 'S' runlevel.  I
fairly quickly saw that mapping those dependencies to script ordering
numbers was a hack, albeit a nicely done hack for compatibility; using
the dependencies natively made a lot more sense, though.

I read about upstart when it was first announced, and I dove into the
event model quite extensively, thinking that it might help improve
things.  I never found it particularly intuitive, and in particular the
whole start on starting, start on stopping etc model never really
made much sense to me; it didn't seem like a natural mapping of how the
system worked.  I also, from the beginning, disliked the model of
starting everything that was possible to start, though I did not at the
time see what the alternative would be; it simply never really seemed
like the right model for booting quickly.  (This was reinforced when I
started paying attention to boot time, inspired by the original boot in
5 seconds presentation; upstart's model seemed entirely unsuited for
that exercise.)  I also found the requirement to know how many times
your daemon forked quite obnoxious (even more so the failure mode if you
get it wrong on even one daemon).  These days, dealing with upstart
professionally, it still seems entirely too easy to get upstart confused
and in a difficult to recover state via a single incorrect upstart job,
and I find it one of the most annoying subsystems to deal with; there's
a general feeling of oh, joy, that's probably an upstart issue every
time any issue relating to booting comes up.

By contrast, my initial exposure to systemd (via the systemd for system
administrators blog series and the systemd documentation) was actually
via socket activation, with the dependency mechanism coming later.  The
socket activation model, as a replacement for dependencies, was one of
those rare ideas that seemed immediately obvious in hindsight.  My
introduction to systemd's dependencies was more along the lines of and
explicit dependencies exist for when you can't fix your daemon and unit
file to do things the *right* way.  Similarly, the use of autofs and
other techniques to allow starting things in parallel even when
dependencies exist made immediate sense.  And the entire model,
including its handling of asynchronous events (notably the integration
with udev), simply felt like a closer fit to how the kernel works and
how reality works.  Finally, the concept of factoring out common
elements from daemons seemed quite nice, having dealt with quite a bit
of ugly boilerplate code.

In both cases, I had no particular reason to like or dislike either
model; in each case I very much *wanted* them to work out, since my
exposure to sysvinit versus startpar gave me a very early reason to want
something better than sysvinit.  I had no other reason to prefer one
model over the other.  I'm not attached to either init system, nor do I
have any particular bias or reason to favor one over the other for any
reason other than superior technology or a model I find clearer and more
natural.

So, in summary, upon initial introduction, I found systemd's model far
more intuitive, both innately (in its use of socket activation and
similar mechanisms to *avoid* dependencies) and as a more natural
mapping to how the system, kernel, and hardware work.

I hope this writeup of my first impressions of both systems proves
useful in some way.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131231032827.GA14382@leaf

Re: Bug#727708: init system other points, and conclusion

[Josh Triplett]

Steve Langasek wrote:
 On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
 Please recall the context here: this whole aside started with an objection
 to my contention that adopting upstart requires disassembly and redoing of
 an integration that we would otherwise not have to disassemble.  Nowhere
 in my message did I say that we would or could not do that disassembly if
 we adopted upstart; I said that it was work that we otherwise wouldn't
 have to do.

 That's the intended context of my point above: I don't think we're going
 to port GNOME to a non-systemd infrastructure, in the sense of carrying
 significant patches to GNOME to adopt it to, say, not using logind.  I
 think GNOME will continue to use systemd APIs heavily, which makes GNOME
 less portable.  That means that systems that are not capable of running
 those systemd components will need to either port them or develop
 alternatives.

 I don't consider this wailing or gnashing of teeth, but rather a realistic
 look at what efforts the project is talking about committing to, as
 opposed to supporting people working on if they so choose.

 Ok.  I think our core point of disagreement here, then, is in our assessment
 of how much work we think this actually is (for the Linux case, not for the
 non-Linux case).  I think the actual package maintenance to make this happen
 is not even a weekend's worth of free time, and therefore represents a
 negligible committment of resources on Debian's part, given that this
 dissassembly/integration has already been done in Ubuntu.

I'm making the assumption, here, that the work you're talking about is
making logind and other such services run without systemd, rather than
attempting to make GNOME and other desktop environments run without
those services.

I think you're underestimating the amount of *ongoing* effort required
here.  I'd point out that systemd in Debian is still stuck at version
204, despite the very nice features available in 205 and newer,
specifically because logind dared to make use of those features.  I
fully expect systemd to continue producing new and interesting features
and *using* them, requiring alternative implementations to either
reimplement more of systemd or create an increasingly invasive fork of
it.  And while I think it's *possible* to continue doing so on an
ongoing basis, that's work that could be spent on other productive tasks
that don't involve reimplementation.

In any case, I sincerely hope that the cost of doing that work is borne
entirely by people who find it a worthwhile activity rather than a
monumental waste of time.  And I furthermore hope that an unmangled and
unforked version of systemd continues to be available in Debian for
folks who want to run the init system that continues to create
functionality so useful that the proponents of upstart are willing to do
a huge amount of work in order to adopt most of it other than the init
system itself.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131231051050.GA18715@leaf