Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Uoti Urpala]

On Sun, 24 Feb 2019 14:16:03 +0100 Johannes Schauer  wrote:
> I found that some important arguments are still missing. A recent mail by
> Guillem [1] nicely summarizes also many of my own thoughts. I'm going to paste
> the relevant content into this mail for convenience of the reader:

I think those have actually been addressed before, even if they're not
explicitly listed or refuted in the draft.

Guillem seems to accept moving away from current filesystem layout, but
also opposes the resulting layout used by other distributions (which
includes the /bin -> /usr/bin symlink). Do you share that view?

The main issue with Guillem's view is that in practice it would make
the transition more cumbersome and error-prone. If there is no
directory-level symlink, then migrating things requires either creating
individual symlinks for everything instead, or having a flag day to
make sure nothing references the old location any more. In practice
either of those is more problematic than a directory symlink.


> > 1) The merged-/usr-via-symlinks deployment method used by both
> >debootstrap and usrmerge, means that those systems will get
> >permanent filesystem aliasing problems, forever. Even when all
> >files might have been moved to their /usr counterparts in the
> >packages! This is due to the fact that different pathnames can
> >end up pointing (before any canonicalization!) to the same dentry.
> > 
> >This does not only affect dpkg (dpkg, dpkg-divert, dpkg-trigger,
> >etc), and update-alternatives (in a worse way), but any program
> >that uses pathanmes in the filesystem as keys in databases f.ex.

This has already been in use, both in Debian and in other
distributions, for quite some time. No major problems have been
reported. Arguing about "any program" is not useful when discussing
only Debian choices, because the layout is used by other distributions
in any case and programs have to cope.


> > 2) It bypasses the packaging system understanding of what is on the
> >filesystem and creates mismatches between what's on binary packages
> >and what's on disk.

This also has not caused major problems, but it can be solved
straightforwardly in dpkg if needed. Dpkg can special-case any legacy
/bin path contained in a package and internally change it to /usr/bin.


> > 3) Switching packages to the merged-/usr layout could have been
> >accomplished automatically via debhelper for a coverage of around
> >99% (?) of the archive. With something along the lines of:

This would just create a more cumbersome and error-prone migration.


> > 4) Due to having to support the broken merged-/usr-via-symlinks
> >deployment, when we want to move the contents of the binary
> >packages to the merged-/usr layout, we require now to include tons
> >of logic in (probably new) maintainer scripts, when we have been
> >trying to remove them altogether. :( With even more files untracked
> >by dpkg itself, bypassing the packaging system even more, when the
> >compat symlinks could have been shipped in the binary packages.

This seems to be based on questionable implicit assumptions. Namely
that the move would want to create an individual per-file compatibility
symlink in /bin for non-merged systems, and this is the part which
would cause problems. There seem to be neither technical reasons to
prefer non-merged systems for any use nor practical difficulties
migrating existing systems to the merged layout, so long-term it seems
OK to deal with this by just requiring merged-usr and not shipping any
individual compatibility links for non-merged systems. This allows the
simplest possible move - just install the files in /usr normally.


> > 5) Most new installations will not even benefit from this hacky and
> >rushed deployment, as long as they do not use a separate parition
> >for /usr!

Is there a point to this? Yes, migrating to merged /usr is mostly an
internal implementation detail for most users. But this does not
exactly give any argument against the migration, other than calling it
"hacky and rushed" while it seems to be the most practical way to do
things.


> > 6) The merged-/usr-via-symlinks deployment hack is irreversible right
> >now.

This is not a reason to avoid using the merged-usr layout.


> Just like Guillem, I'm personally not against merged-/usr but against how we
> implement it.

Not against, except for the directory symlinks being part of the
merged-usr layout?

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Uoti Urpala]

On Sat, 10 Dec 2016 06:54:17 +1030 Ron  wrote:
> You then had the gall to angrily insist that while you thought he might
> be a better maintainer than me, it was still my responsibility to do the
> work to fix all the obvious things that others had missed in their fork
> (which he hadn't contributed anything to either).  I'm afraid that's not
> how encouraging volunteers to contribute their time for you works ...
> sorry if this is news to you.

It was perfectly reasonable to ask that if you have any pretense at all
of actually doing the work expected of your maintainer position, you'd
contribute to creating packaging for the new upstream version, instead
of only attacking the people working on it.


> things.  But because the increasingly ill-named technical committee has once
> again refused to stick its collective necks out to actually offer technical
> advice when explicitly asked to.  We chopped some heads off the hydra, but

> Explaining things in careful detail has had every appearance of being a
> complete waste of my time whichever way this might have ended up.  The only

The fundamental problem with most of your technical arguments was that
they were arguments about upstream development, not about packaging.
Even if they were 100% true, they still would not justify how you have
handled the Debian package. If you disagree with upstream that way, you
should try to convince them, and if that fails and you care enough,
create a new upstream fork.

Instead, you turned the Debian packaging into a practical fork. That's
not the right place for hosting a new fork. You also obviously did a
bad job of maintaining your fork (given the complete lack of
development). Your attitude seems to have been that you insist on
keeping the original GLOBAL out of Debian, do no development at all
yourself, and if anyone has problems with your fork you insist that
they do the work of developing it. That's not reasonable at all.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Uoti Urpala]

On Mon, 21 Nov 2016 17:16:34 +1030 Ron  wrote:
> If we run with your proposal, what are you actually suggesting we tell
> the people who'd be upset by the loss of htags without notice in Stretch?
> Because I don't really see how you've addressed that here.
> 
> AFAICS, there's just either an implicit "Sucks to be you", or an
> implication that this is a simple "regression" which might be fixed
> by sending patches upstream.

Assuming the htags functionality really can't be supported with a newer
upstream version: tell people that the functionality is no longer
available in current GLOBAL. If someone - including you - thinks this
is a major problem and wants to provide an alternative, a fork
providing this functionality can be packaged. Under a name other than
"global".


> FWIW, I actually agree with a lot of the general rules of thumb that
> you outlined here, about how things should work in the normal case.
> But this isn't really a "normal" case, if it was we wouldn't be talking
> about this here at all.  What to do would be obvious to everyone.

There's nothing particularly "abnormal" about disagreeing with upstream
decisions. What is unusual, and is the reason why this has been
escalated here, is how badly you have handled the situation in your
packaging.


> The group complaining loudly now have basically squandered the entire
> release cycle by not reporting actionable bugs about what they need,
> and haven't sent any patches to remedy that.  And they are proposing

If anyone has "squandered the release cycle", it's you. You already
knew, or should have known, that the package was in an untenable state.
You've failed to fix the situation for years. You don't get to blame
other people for that.

> 

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Uoti Urpala]

On Tue, 8 Nov 2016 15:33:32 +1030 Ron  wrote:
> On Mon, Nov 07, 2016 at 12:09:21PM -0800, Nikolaus Rath wrote:
> > It seems you're only interested in impartial and non-partisan voices
> > when they happen to back your position. I am impartial and non-partisan,
> > and formed my opinion by reading the bugs and your emails.
> 
> And "your opinion" still hasn't said even a single word to show that you
> understand the technical problem here, or to offer any solution to it.
> The problem which doesn't just magically go away regardless of who might
> implement it.

Even if your technical concerns were correct, they do not justify your
handling of the package. Saying that your actions have been wrong, and
the package needs to be handled differently, does not require
addressing the technical CGI issues in any way. You have no basis to
insist that people care about the CGI issue or try to solve it before
commenting on other handling of the package.


> > If you indeed welcome opinions from people like me, your statements
> > above are a little odd.
> 
> I think you missed the bit about "comprehending the problem and building
> consensus on solutions" - because if this is all you have to offer then
> no, "opinions" from people "like you" are neither helpful nor welcome.
> Even if they 100% agree with me.  They are just a toxic symptom of people
> still ignoring the hard technical problem.

"The problem" here is the way you've blocked the package at an ancient
version. Fixing this does not require creating a perfect CGI framework
or in any other way fixing all upstream issues and making the software
perfect. Maybe _you_ really care about the CGI issue. But if nobody -
including you - cares enough to create a perfect solution, then it'll
be broken. Too bad, but even if you're really disappointed, holding the
package indefinitely at an obsolete version is not an acceptable
response. Again, that nobody has created a perfect upstream does not
justify your handling of the package, and you don't get to blame others
or call their behavior "toxic" because of that.


> details of _what_ we ought to do.  If we don't solve that, then who does
> it is kind of irrelevant, there'll still be a Hard Problem that someone
> won't be happy with.

You keep talking about Hard Problems and how others must solve them to
be allowed to criticize your actions or actually do anything to change
the status quo that you've failed to improve for several years. That's
bullshit. If someone packages a new upstream without solving those
issues, that'll be perfectly acceptable. Fixing software to be perfect
is not a requirement for packaging, and creating a package that lacks
some desired functionality when upstream lacks it is OK. The way you've
handled the package is not OK.

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Uoti Urpala]

Note: this is written as an outsider who doesn't have any direct stake
in the issue.

On Sun, 6 Nov 2016 05:00:12 +1030 Ron  wrote:
> > And I think the latter is basically what the "just ship multiple
> versions and hope the future gets clearer" option boils down to.
> All it really does is take the pressure off of everyone but me
> to have any interest at all in actually trying to resolve the
> genuinely Hard part of this.  And it does that by making an even

I don't think the others have any obligation to try to resolve any
technical issues, and it is 100% reasonable of them to insist that
Debian just ship a new upstream version (as long as the packaging is
not otherwise unacceptably bad; but simply disabling any functionality
that is not secure or otherwise OK upstream is a valid answer).

Based on what I've seen in this thread, I think I can say you're
clearly in the wrong. And that does not require considering any of the
technical issues with the software. The software now shipped in Debian
as "global" is simply too outdated compared to upstream. That you have
technical objections to something in the newer versions could be a
reason for you to create a new fork. But you have not properly done
that, and abusing your Debian packager position to indefinitely hold
back the package is not an appropriate answer to any technical issues,
regardless of the validity of the technical objections.

To properly create a fork, you'd need to either pick a new name for
your fork, or contest whose version has the right to the name "GLOBAL".
You have obviously not chosen a new name. You don't seem to be claiming
to be the overall upstream maintainer of GLOBAL either, and claiming
that would be totally inappropriate if you're only shipping your
version in Debian. As such, you have no business shipping your version
under the "global" package name. Either ship the upstream version -
even if flawed and causing problems for some users - or use another
package name.

Bug#830978: Browserified javascript and DFSG 2

[Uoti Urpala]

On Mon, 18 Jul 2016 11:15:59 +0200 Philip Hands <p...@hands.com> wrote:
> Uoti Urpala <uoti.urp...@pp1.inet.fi> writes:
> 
> > In what sense couldn't everyone modify the concatenated form?
> 
> Perhaps if I frame my question from:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#90
> 
> in another way, I'll get an answer.

Isn't this the separate issue Ansgar already mentioned in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#45

Bug#830978: Browserified javascript and DFSG 2

[Uoti Urpala]

On Mon, 18 Jul 2016 09:02:08 +1000 Ben Finney <ben+deb...@benfinney.id.
au> wrote:
> On 17-Jul-2016, Uoti Urpala wrote:

> > If you want to argue "upstream convenience" as a reason for the
> > second,
> 
> Maybe if that were the only justification offered. That's not the case
> though.
> 
> 
> Reading the discussion on debian-devel, and even reading the
> discussion in this bug report, the argument for the source form of the
> work rests on *whether* the form of the work allows modification on an
> equal basis with upstream.
> 
> Neil Williams puts it well in this same bug report:
> 
> Where one format can be modified by every user and another format
> can only be modified by some users, then the format which can be
> modified by everyone *must* be the accepted format or the package
> fails DFSG. When the second format is actually generated from the
> first format and cannot exactly regenerate the first from the
> second, it is obvious that the second format is not the source
> code in terms of the DFSG as changes to the second would be lost
> when the first is updated and the second gets regenerated.
> 
> <URL:https://bugs.debian.org/830978#95>;
> 
> Nothing about “upstream convenience” there.

That's exactly the post I was replying to, and it does spend a lot of
time talking about ability to get the changes upstream - both from
upstream point of view and ability of the person doing the changes to
get them there.

As for this particular quote, the terminology of "a format that can be
modified by every user" is not clear at all to me. In what sense
couldn't everyone modify the concatenated form?

And if you get too picky about preferred format, then that's a git
repo, not a tarball. If I want to make upstreamable changes to some
software in Debian, then first I clone the upstream git; that's the
form I prefer for doing modifications, and the single-version tarball
exports Debian distributes are a distinctly inferior form generated
from that.

> It's about equal access,
> for all recipients of the work, to make and share their own build from
> the source form of the work.
> 
> That entails receiving the work in such a form, and with all necessary
> build scripts, to make modifications (or choose not to modify) and
> build the work themselves to get the same result. That is, in brief,
> the source form of the work.
> 
> Without the form of the work that is the *input* to the build tools,
> and the build tools and script themselves as free software in Debian,
> then the recipient cannot be said to have what they need to exercise
> DFSG freedoms.

You're not really saying anything meaningful here IMO. The recipients
would be able to make modifications to a concatenated form and build
the work themselves to get the same result. They would have all the
necessary build scripts etc to do the work. So what you're talking
about here does not in any way imply they wouldn't have the source. Of
course, if you've already declared that what they have isn't source
then there's a problem - but unless you _start_ from that assumption,
what you write above does not give any criteria which could be used to
arrive to that conclusion.

Bug#830978: Browserified javascript and DFSG 2

[Uoti Urpala]

On Sat, 16 Jul 2016 00:02:55 +0100 Neil Williams 
wrote:
> On Fri, 15 Jul 2016 23:45:01 +0530
> Pirate Praveen  wrote:
>> If this argument is accepted, we will not be able to package a fork
>> because the original upstream won't accept a patch against the fork.
>> Similarly we'd be able to package only HEAD of the vcs as they
>> usually accept patched only against HEAD. Porting patches is an
>> essential part of packaging. By choosing to maintain this source, I
>> accept this challenge. If I cannot keep the package rc bug free
>> otherwise, it will be removed any way.

I think the part about packaging only VCS HEAD is an excellent point,
and really needs to be addressed by people who want to argue that
concatenating files should be an RC bug.


> Where do you get this crazy and fanciful notion that upstream are
> somehow second-class community members? Upstream are users of the

I don't think he was saying that at all. If I consider this from an
upstream point of view, I'd say that the packaging being behind latest
upstream version is a more significant issue than the packaging using
source transformations like concatenating files. People who want to
make large, complex changes are likely to use upstream files directly
anyway, so that limits the extra work caused by working around such
transformations. Packaging old versions causes similar issues for
patches based on outdated code, and additionally several other issues,
like preventing upstream from getting timely feedback about changes and
causing upstream to receive complaints about already fixed bugs.

In essence, my central point is that you cannot consistently believe
BOTH of these:
* packaging not being up to date with latest upstream is just a
  wishlist bug
* packaging concatenating source files is such a horrible bug that the
  package should be removed from Debian

If you want to argue "upstream convenience" as a reason for the second,
then you must also accept that being behind latest upstream is a lot
more serious than wishlist.

If the TC wants to make a statement against concatenating files, then I
hope any such statement also mentions that being behind latest upstream
should be considered an equally serious bug. If the TC is not willing
to consider such an addition, then they should IMO also reconsider
whether it's really valid to use upstream preferences as a
justification for such a statement at all.

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

[Uoti Urpala]

On Mon, 20 Oct 2014 10:06:31 -0400 Martin Pitt mp...@debian.org wrote:
 I'll leave this to the Debian maintainers, as I'm mostly responsible
 for the Ubuntu side, haven't really discussed this with the two
 Michaels/Tollef/Marco, and I don't feel qualified to speak for the
 Debian systemd team.
 
 My personal opinion: Given how close we are to the release and how
 many regression reports we still get, it seems prudent to not change
 the currently running init systems for upgrades for Jessie yet, but
 only set up systemd for new installs. I know this is not really in the
 spirit of the TC decision to make systemd the default init system, but
 at this point in time it might be the pragmatic compromise.
 
 The systemd package gets literally swamped with bug reports (of all
 kinds of usefulness/quality), and there's simply not enough
 maintainers to keep up with the flood. Many of those are indeed not
 actual bugs in systemd, but bugs in other packages, local

That swamped with bug reports does not match my impression of reading
the systemd packaging list. As far as I can tell, this is not the view
of the Debian maintainers either.

My impression from the bug reports is that systemd-shim does not work
particularly reliably. So automatically installing systemd-shim does not
seem any safer than automatically installing systemd from the view of
avoiding breaking old systems.


 The other direction (running sysvinit or upstart with -shim) has not
 been so unproblematic though, as systemd-shim's bug list shows. This
 definitively needs some love, but then again we've run this for a fair
 while in Ubuntu (even in our 14.04 LTS) without too many problems. So
 my feeling is that we can certainly stabilize -shim by the jessie
 release. (We need to do that anyway, as we need to support sysvinit
 regardless of what we do on upgrades/new installs.)

Is there some reason to believe that there would be _more_ success with
this than with resolving the remaining integration issues with systemd?
And shouldn't work on the latter be higher priority?


-- 
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/1413908276.29980.1.ca...@pp1.inet.fi

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

[Uoti Urpala]

On Thu, 2014-09-18 at 17:14 -0700, Cameron Norman wrote:
 On Thu, Sep 18, 2014 at 2:10 PM, Josh Triplett j...@joshtriplett.org wrote:
  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.
 
 As you hopefully can see, this can be condensed to systemd-sysv ?
 systemd-sysv : systemd-shim AKA systemd-shim | systemd-sysv :)

You completely missed the point, which was to distinguish between
systems that have explicitly installed the new use-sysvinit-as-init
package and systems that only use sysvinit because they have not yet
upgraded to the new default. Neither of those have systemd-sysv
installed, thus your version does not work.


From another mail:
 If the transition is already happening, why have the dependency be
 like it is anyway? User's systems will be switched regardless, so
 there is no use in having a second pass at changing the init.

For partial upgrades.


-- 
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/1411128134.1645.5.ca...@pp1.inet.fi

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

[Uoti Urpala]

On Thu, 2014-09-18 at 12:23 -0700, Steve Langasek wrote:
 On Thu, Sep 18, 2014 at 11:36:54AM -0700, Josh Triplett wrote:
  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,
 
 And yet you are arguing that the libpam-systemd dependency should not be
 inverted, for political (not technical) reasons.

He did give *technical* reasons to not invert the dependency. I also
agree that it's suboptimal if the init system changes as a side effect
of upgrading/installing some other, seemingly unrelated, package.
However, that does not make it a good idea to install shim as a side
effect instead. At least the case where you do partial upgrades of
packages that now add a libpam-systemd dependency is one where
systemd-sysv first seems technically correct (more below).

When doing partial upgrades, I think the ideal user experience would be
to inform the user that he should do the migration to systemd at this
point before proceeding to update certain individual packages to newer
versions.


 If we decide that init *should* be automatically changed on upgrade, then
 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.

It is also relevant if someone does a partial upgrade to current
unstable from an older system that still uses sysvinit for legacy
reasons only (and is expected to switch to systemd at *some* point in
any case). Installing shim would make the user waste effort dealing with
shim's problems, while still requiring them to deal with any
incompatibilities from the systemd transition at a later point.
Deferring some issues in this way while increasing the amount of overall
work and problems could be a valid choice in particular cases, but I do
not thing it should be the default behavior.


 If the bugs in systemd-shim are too severe to allow it to be used with
 logind (a claim that I do not agree with - and I think you and Michael are
 moving the goalposts by using the existence of bugs in
 cgmanager+systemd-shim /in general/ as a justification for delaying the
 change in dependency order), then those bugs should be marked as
 release-critical, and the determination should be made by the usual means
 whether systemd-shim should be included in the release.  But it is not for

There is a difference between a package that's functional enough to be
useful for people who know what they're doing, and a package that's
suitable to be automatically installed just because people do partial
upgrades in a particular order. And it seems that systemd-shim falls in
the first camp (though I have not followed it closely myself). It may
not be RC-buggy, but not RC-buggy is not a sufficient quality
criterion to install it automatically if a user just wants newer GNOME
packages for example.


-- 
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/1411076173.1645.3.ca...@pp1.inet.fi

Bug#727708: Processed: block 726763 with 727708

[Uoti Urpala]

On Tue, 2014-02-04 at 16:53 +, Colin Watson wrote:
 On Sun, Feb 02, 2014 at 12:57:39PM +0100, Tollef Fog Heen wrote:
  You mean, like installing the systemd-sysv package?
 
 Indeed; but people earlier in this thread have said that this isn't the
 preferred approach, so I was arguing that this *should* be the preferred
 approach in Debian if systemd is selected as the default, rather than
 having helper packages that have to wander around fiddling with the
 configuration of half a dozen different boot loaders to point them to
 the right place.
 
 If the people whose comments I was reading weren't accurately reflecting
 the position of the Debian systemd maintainers, then I apologise for
 misunderstanding.

The main issue is that systemd-sysv conflicts with sysvinit-core, while
the systemd package doesn't. If you do the first install of systemd with
systemd-sysv, this doesn't only change the default, but forces the
removal of the whole sysvinit implementation. This can be compared to a
kernel package install that forces the removal of all previously
installed kernels before you can boot to the new one.

So the systemd-sysv route has the clear technical disadvantage that it
does not support parallel installation of sysvinit and systemd. I think
the ability to easily switch back to sysvinit for troubleshooting if you
encounter issues does have some value. Of course, it would be possible
to switch /sbin/init while both are installed.


-- 
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/1391539390.2272.40.camel@glyph.nonexistent.invalid

Bug#727708: TC resolution revised draft

[Uoti Urpala]

On Sat, 2014-02-01 at 17:10 +, Ian Jackson wrote:
 Sébastien Villemot writes (Bug#727708: TC resolution revised draft):
  P1: DT  UT  DL  UL
  P2: DL  UL  DT  UT
  P3: UT  UL  DL  DT
  P4: UT  UL  DL  DT
 
 This is a nice example which actually demonstrates why these questions
 need to be voted on in a single ballot.
 
 If one votes on T-vs-L before U-vs-D, P3 and P4 don't know how to vote
 on T-vs-L until they know how the vote on U-vs-D will turn out.

I believe that part was just a typo in the message you're replying to,
and it should be UT  UL  DT  DL for P3 and P4. He wouldn't have
written about relative importance of these two questions if he had
intended the answer to one question to change depending on the answer to
the other.

So his example was one where the D/U and L/T choices were independent
for every voter, but combining them into a single ballot produced a
result different from the expected result of voting on each independent
question separately.


-- 
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/1391277909.2272.10.camel@glyph.nonexistent.invalid

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

[Uoti Urpala]

On Tue, 2014-01-28 at 22:20 +0200, Adrian Bunk wrote:
 On Tue, Jan 28, 2014 at 12:08:19PM -0800, Don Armstrong wrote:
  On Tue, 28 Jan 2014, Zbigniew Jędrzejewski-Szmek wrote:
   On Tue, Jan 28, 2014 at 11:23:11AM -0800, Don Armstrong wrote:
The former. So :

   Where feasible, software should interoperate with non-default init
   systems; maintainers are encouraged to accept technically sound
   patches to enable interoperation, even if it results in degraded
   operation while running under the non-default init.
  
   Maybe I'm dense...
   
   Scenario: Let's say that OpenRC is the new default init and in the
   meanwhile, Gnome has gained a dependency on systemd. A patch to
   support Upstart in Gnome is posted that partially breaks the
   functionality under systemd.
   
   By your wording, maintainers are encouraged to accept the patch.
  
  No. This was precisely the ambiguity which Neil (correctly) pointed out.
  Simply put, patches which reduced existing functionality while running
  under the default init (say, systemd), would not be technically sound.
  
  Instead, maintainers are encouraged to accept the patch even if it
  results in reduced functionality while running under the non-default
  init (say, upstart) in comparison to the default init (say, systemd).
 
 That's a different case.
 
 Zbigniew was talking about a package that has a dependency on a
 *non*default init system.
 
 And for that the first question is whether such a dependency on a 
 *non*default init would be allowed at all.

Not really. What Zbigniew was talking about was whether the above
wording would allow a patch enabling operation with system A to degrade
existing functionality with *another* system B (whether B is actually a
strict dependency does not seem that important). This depends on how
you interpret the non-default init; Don obviously meant this to refer
to the same init as the patch is for.

I think this kind of possible ambiguity could be avoided by phrasing
like even if the patch only implements a degraded mode of operation
under this system, to make it clear that the degrade does not refer
to any functionality that existed _before_ the patch.


-- 
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/1390942291.4304.222.camel@glyph.nonexistent.invalid

Bug#727708: On diversity

[Uoti Urpala]

On Thu, 2014-01-16 at 17:00 -0800, Russ Allbery wrote:
 Uoti Urpala uoti.urp...@pp1.inet.fi writes:
  I think the divergence has gone too far in things like non-Linux ports.
  They have had an overall negative effect on people working on Linux
  within Debian and people creating derivatives.
 
 I have to take exception to this.  There has been a great deal of
 *concern* from people over the past two years that the non-Linux ports
 *might* have a negative effect on Linux in the context of this particular
 discussion.

I consider the effect on the init system decision process so far to
already be an example of actual negative effects. Even if it does not
ultimately lead to an inferior system being chosen for Linux (which
would be a major harm), the portion of discussion that has been about
non-Linux ports has been completely out of proportion compared to their
potential benefit/importance, has made the decision process harder, and
has made it more difficult for anyone else to follow the discussion or
form an informed opinion based on it.

   But, in the meantime, the non-Linux porters have been
 first-class Debian contributors over the years.  They have not
 substantially gotten in the way of Debian's processes, certainly no more
 than any Linux port to a more obscure architecture,

I don't have any numbers, but I would be surprised if that no more
than were true. The kernel and compiler already abstract away most of
hardware differences, and ignoring toolchain issues, I'd expect most of
hardware-specific failures to be things that could be considered general
bugs in the software even on platforms where it works. By comparison,
changes required by kernel differences are generally not positive on
other platforms.

  and they have
 contributed a great many improvements to our software.
 
 For example, I think special thanks should go to the Hurd porters for
 extended, thankless work on removing static buffers from the code in the
 archive.  They were doing so because some of the constants used to size
 those buffers are not portable to the Hurd, but using static buffers to
 store paths and related strings is often incorrect regardless of its
 portability, and can even be a security issue depending on how the code is
 written.  The Hurd porters have provided reasonable patches that can go
 back to upstream and result in objectively more robust software.  I have

Those are probably among the most useful patches, but I think they're
still very minor, and not worth the maintainer work adding distro-
specific patches in Debian (as opposed to letting it become part of
upstream code). Most changes will not be useful on other kernels.

There are also other costs. For example, kFreeBSD issues have prevented
testing migration of packages. Even if systemd is chosen as Linux init,
will everyone packaging daemons or other software interacting with init
for Debian be expected to remember guidelines or even do things
differently because of issues that only matter for non-Linux?

zgrep -i kfreebsd /usr/share/doc/*/changelog.Debian.gz shows over 1000
different matches just on this machine. Of course some of those packages
could be maintained by people who personally really wanted to work on
kFreeBSD regardless of its value, but I doubt the majority is. IMO
justifying that amount of work, and claiming that kFreeBSD has not had a
negative effect, requires showing some concrete benefit.


-- 
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/1390442078.4304.209.camel@glyph.nonexistent.invalid

Bug#727708: On diversity

[Uoti Urpala]

On Fri, 2014-01-17 at 16:08 +0100, Ihar Filipau wrote:
 Uoti Urpala wrote:
  Even the upstart proponents do not seem to have significant arguments
  about upstart having better functionality, and there don't seem to be
  all that many people who would have a reasonably informed opinion that
  upstart would be technically better even for just their particular use.
 
 I followed the discussion from the beginning and I'd like to comment on that.
 My own comparison of systemd vs. upstart (Fedora 20 vs. Ubuntu 13.10) is still
 fresh in my memory.

Your comparison does not look very informed, see below.


 1. upstart is a highly configurable init system, while systemd hardcodes
 most of the nuts and bolts in the 32 shipped executables. I spent one days

Your hardcodes is wrong: systemd ships with helper executables and a
default boot setup which uses those, but they're not hardcoded and you
can use something else if you have a reason to.

 So here you go. The advantage of the upstart, is that if you need to tweak the
 boot of your system, you can do it right there, with the text editor, by
 changing the .conf files or the shell scripts. While with the systemd, you 
 have

I strongly disagree that using shell more as an implementation language
would be a good thing. But out of the things in your post I think this
is the closest to a not-factually-incorrect personal preference someone
could have for upstart: some people could prefer working in shell only.
However, this isn't really a comparison of the init systems themselves
so much as a comparison of the default boot setups shipped with the
inits. Even if you decide that almost every program running on your
system should be implemented in shell only, you could still use systemd
to start those programs, though you'd need to change more of the default
configuration if you wanted to avoid starting anything non-shell at
boot.


 2. upstart was not designed or intended to be a SMF (service management
 facility), while systemd was.
 
 I think it is insincere of upstart proponents to even advertise it as such. On

 On the other side of the fence. As I see it, it is only a coincidence that
 systemd is also an init system. To me it was clearly designed from ground up
 as SMF: boot and initialization were only afterthought. That's why the magic
 binaries, because the initialization, an event driven process, simply doesn't
 fit into the systemd everything is a service model.

This is nonsense. Technically, the choice of implementation language for
the binaries/scripts and the event/dependency model are completely
orthogonal. This means your last sentence is completely wrong. It's also
not plausible as a historical fact that boot would have been an
afterthought.


 3. Boot times. Though systemd was supposed to improve the boot time, Fedora 20
 VM on my rig needs 1m5s-1m15s to start - while Ubuntu 13.10 VM always timed
 flat 0m35s. That was pretty dumbfounding realization, especially after finding

Other people have Fedora booting a lot faster. There are lots of reasons
that could make boot slow other than inherent problems with the init
system, so if you haven't done any analysis of the causes of the
slowness, this does not really tell anything.


-- 
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/1389981988.4304.154.camel@glyph.nonexistent.invalid

Bug#727708: On diversity

[Uoti Urpala]

On Thu, 2014-01-16 at 17:52 +, Ian Jackson wrote:
 * Debian is a forum for cooperation and technical development.

 * Debian, as a piece of software, tries to be all things to all
   people (within reason).

 This flexibility and tolerance for divergence has made Debian an
 extremely attractive target for everyone to work within, work on, and
 derive from.  I think it has been key to the success of the project.

I think the divergence has gone too far in things like non-Linux ports.
They have had an overall negative effect on people working on Linux
within Debian and people creating derivatives.


 I passionately believe that we need to retain this aspect of our
 community, even if that causes us extra work; and even if it causes
 friction with those who would like to make the world nice and simple
 by only supporting certain goals, certain use cases, or certain
 software.
 
 
 Now let me apply that to init systems:

Even if you start from the assumption that diversity is positive, you
can't justify support for any particular system without analyzing costs
and possible alternative goals. Is support for multiple init systems
more important than having a good SELinux policy for each package? Being
able to compile packages with several different compilers? Just fixing
more known bugs in existing packages? You could come up with hundreds of
possible goals that would all have at least some positive effect; just
saying that diversity is good can't allow you to pick some and reject
others.


 If you think that the difference between upstart and systemd, or
 between either of those and systemd, is not important, then perhaps
 you could conclude that it was OK to impose a particular decision on
 all of our users and all of our downstreams.

I think there are important differences: upstart is significantly worse
than systemd in several areas.

 But I think the differences /are/ important.

Do you actually believe that upstart has some nontrivial technical
advantages over systemd, such that it would be a noticeably better
alternative even when considering only some specific use case? IIRC you
did not identify any when saying you preferred upstart earlier, and
mainly based your opinion on the assumption that upstart would be more
likely to get ported.

Even the upstart proponents do not seem to have significant arguments
about upstart having better functionality, and there don't seem to be
all that many people who would have a reasonably informed opinion that
upstart would be technically better even for just their particular use.
To me it looks like the main reason Upstart is still alive at all is
that Ubuntu don't want to pay the cost of the conversion to the better
system and don't want to admit that their alternative was inferior.

If the differences are mainly just it's worse rather than tradeoffs
where each software has clear technical advantages, it's unlikely
diversity would give any significant benefits.


 That means that we need to be the venue where systemd proponents, and
 upstart proponents, and openrc proponents, can make the best system
 they can.

I do not believe it is possible to create such a venue. The result of
the kind of everything must be supported policies you seem to favor
would be a venue where nobody is able to create a system they would be
happy with. Or possibly only sysvinit/openrc proponents would be happy
with, if everything is dumbed down to the level where those systems can
handle it.

 Naturally that will involve some compromises.  That's an unavoidable
 cost of trying to be the best place for everyone to pursue their own
 goals.

The best place for everyone to pursue their own goals is
self-contradictory. You need to choose whose goals matter most; if you
don't, it'll require so many compromises that it's not only not the
best place for most, it outright sucks. Everyone can maintain their own
leaf package, but not everyone can design how boot and service
management should work.

 I think in this case those compromises are absolutely essential.  Not
 just from a technical point of view because of the advantages of one
 system over another.  But also to ensure that Debian continues to be
 the place where serious and dynamic people come to do their stuff.

Debian has been successful in some ways, but I don't think it is the
place where serious and dynamic people come to do their stuff. For
example, none of the newer init systems come from Debian itself; I think
that reflects how hard it is to create the kind of progress I'd
associate with the word dynamic within Debian. Debian mainly
integrates serious new developments long after they've been used
elsewhere.


-- 
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/1389919551.4304.123.camel@glyph.nonexistent.invalid

Bug#727708: init system discussion status

[Uoti Urpala]

On Fri, 2014-01-03 at 10:02 -0800, Nikolaus Rath wrote:
 Ian Jackson ijack...@chiark.greenend.org.uk writes:
  | 3. At least in jessie, unless a satisfactory compatibility approach is
  |developed and deployed (see paragraph 10), packages must continue
  |to provide sysvinit scripts.  Lack of a sysvinit script (for a
  |daemon which contains integration with at least one other init
  |system) is an RC bug in jessie.
 
 
 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.

Even restricted to just service startup, I think that's a rather strict
limitation. Suppose an upstream releases a new daemon that is intended
to be used with systemd using socket activation, and as such does not
contain any code to do double-forking or open listening sockets. Would
it be forbidden to package this daemon in Debian unless the maintainers
are willing to add forking, other startup and socket code as Debian-
specific patches? If it would, how much functionality would the
maintainers need to add for a minimal accepted version - for example
would they need to add new options to specify which port to listen on,
or is opening a hard-coded default port enough for the added socket
code? Adding support for everything that systemd socket activation
automatically supports would not be realistic.


-- 
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/1388775476.3938.447.camel@glyph.nonexistent.invalid

Bug#727708: init system thoughts

[Uoti Urpala]

On Thu, 2014-01-02 at 12:31 +, Colin Watson wrote:
 On Wed, Jan 01, 2014 at 08:15:46PM +0200, Uoti Urpala wrote:
  You can simply not install any of these additional services if you don't
  want them. This is completely trivial to do.
 
 It is indeed technically trivial, but I invite you to review your own

 It's also not, in general, trivial to do something if it involves a
 massive argument, even if the patch would end up being a one-liner.
 Social costs are costs too.

So your position is essentially systemd may be a technically better
init, but it would allow maintainers to choose services I do not like,
so I'll try to pre-empt that by choosing upstart? The obvious
alternative, and IMO correct choice, would be to decide the init on
technical merits and handle choice of services separately (if needed).


  the _best_ way to handle the situation: B thinks that gaining
  compatibility with other distributions is a bigger plus, and that

 Perhaps this is the fundamental disagreement.  I do not necessarily
 consider compatibility as an end in itself.  Where Debian is already

Maybe that's a basic disagreement in discussions concerning specific
services, but certainly not for init system choice. What I view as the
basic reasons I find your given rationale for choosing upstart
completely unsatisfactory:

* I don't think it's appropriate to use the init decision to push your
views on the service choice question, when the latter could be decided
independently regardless.
* Your initial posting of the rationale represented it as a technical
issue. Now you say it's a social one (pre-empting future arguments), but
you still haven't given any real analysis to support your view. No
mention of the obvious alternatives, no estimation of how common service
disagreements would be, almost nothing at all. Basically you've only
mentioned two discussions you didn't like; there's a gap from that to
and therefore this should be resolved by choosing a different init.

I also do not consider it plausible that disagreements over which
services to use could be so bad that they would override all other
concerns in choosing an init system.


-- 
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/1388678640.3938.432.camel@glyph.nonexistent.invalid

Bug#727708: init system thoughts

[Uoti Urpala]

On Wed, 2014-01-01 at 17:17 +, Colin Watson wrote:
 On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
  Colin Watson cjwat...@debian.org writes:
   Basically, systemd would be more compelling to me if it tried to do
   less.  I don't expect to persuade systemd advocates of this, as I think
   it amounts to different basic views of the world, but the basic approach
   here is probably the single biggest factor influencing my position.
  
  On the other hand even when using upstart as an init replacement, we'll
  continue to use large chunks of systemd (logind, other dbus
  services). I personally think less is more would only be a convincing
  argument if we actually would not need the aditional features.

I think this counterargument, while valid, misses the major flaw in the
would be more compelling if it tried to do less claim:

You can simply not install any of these additional services if you don't
want them. This is completely trivial to do. Using systemd as init in no
way requires using them. Thus their existence cannot cause any technical
problems for the use of systemd in Debian (beyond possibly needing to do
the trivial disabling).

If some other components that Debian does want to use start to depend on
those services, such that disabling them is not easy, then this problem
would exist regardless of the chosen init, and is again not a reason for
favor upstart.

 I'm referring to features that I don't think we'll need, not to logind
 et al.  So far I feel that the debates about those seem to be a bit
 circular and go something like this:
 
   A: This feature of systemd conflicts with something else; I'd rather
  we didn't use it.
   B: You can disable that, you know.
   A: OK, let's disable it.
   B: But you shouldn't disable it because that would make Debian systemd
  less compatible with systemd on other distributions.
   A: ...

Here B first correctly points out that the feature can be disabled if
desired, and thus the situation cannot be worse than with upstart - you
can do at least as well with systemd as you could with upstart. Then you
(A) have a disagreement with B about whether disabling the feature is
the _best_ way to handle the situation: B thinks that gaining
compatibility with other distributions is a bigger plus, and that
changing to the systemd way is an actual win over current situation,
rather than just neutral like the the upstart and disabling with systemd
cases.

There is no technical reason to prefer upstart here. Given your
preferences, systemd can do at least as well (after disabling the
service). Given B's preferences, systemd can do better (after enabling
the service). The only benefit that choosing upstart would give you here
is that it'd let you automatically win your argument with B: we already
chose upstart, so enabling the systemd service is not an available
choice any more.


-- 
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/1388600146.3938.402.camel@glyph.nonexistent.invalid

Bug#727708: init system other points, and conclusion

[Uoti Urpala]

On Mon, 2013-12-30 at 18:58 +, Ian Jackson wrote:
 Also, I get the impression me that the integration of much of this
 functionality into the systemd source package has been done for
 political rather than technical reasons.  Indeed to the extent that
 there is a problematically tight technical coupling between these
 components, I find it difficult to avoid doubting the good faith of
 the people making those decisions.  At the very least, I worry that
 the systemd project as a whole is far too willing to impose decisions
 of all kinds on its downstreams.

Your own expressed preference for upstart appeared to be very much
driven by political rather than technical considerations. Using the same
terminology you do, would it not be entirely fair to say that your
decision to support upstart was made in bad faith?


  3.3. Project Momentum
 
 I don't see the outlook here the same way as you do.
 
 Furthermore, I am much less worried about Debian going it alone
 (although, of course, it's not alone) than you seem to be.  We have
 historically been entirely unafraid to do our own better things, even
 if it is more work and takes us longer.
 
 I felt that way when Debian was very much a minority interest.  That's
 far from the case nowadays; I've heard it asserted that Debian-based
 distros now account for a majority of traditional distro installs.  I
 guess numbers on that are all speculative but it is certainly true
 that we have a thriving ecosystem of our own.
 
 We have got where we are by doing things the way we think is best, not
 by simply following the herd.

Who would actually do the work? Getting the amount of development there
is for systemd is not easy. Do you really believe that a Debian decision
in favor of upstart would create that many interested developers working
on it, when that has not happened while it's been used in Ubuntu?

Working on things that they believe to be better than existing ones does
motivate people. But how many Debian developers actually share your
extreme views about portability to the extent that they would be happy
to work on another system motivated by that, when systemd already works
better on Linux? I doubt that group is large enough to create
significant momentum.


-- 
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/1388447089.3938.340.camel@glyph.nonexistent.invalid

Bug#727708: init system thoughts

[Uoti Urpala]

On Tue, 2013-12-31 at 02:55 +, Colin Watson wrote:
 My main concerns with systemd relate to its broad scope regarding units
 it provides for system initialisation tasks currently performed by other
 packages, and the potential for that to interfere with past and future
 work elsewhere in Debian.  I can understand why the systemd authors felt

 The two examples which I've run across so far, both ones I was inclined
 to look at since I'm familiar with the territories, are:
 
   #716812 (binfmt-support)

   #608457 (console-setup)

 Basically, systemd would be more compelling to me if it tried to do
 less.  I don't expect to persuade systemd advocates of this, as I think
 it amounts to different basic views of the world, but the basic approach
 here is probably the single biggest factor influencing my position.

I think this is absolutely ridiculous as a rationale for choosing
upstart. If you have done any investigation, you should know that it's
trivial to disable any of those components if Debian decides it's better
off without them. Yet you really seriously present their existence as
the biggest factor influencing your position? In what kind of scenario
could their existence possibly cause noticeable problems for Debian
systemd use?

I can imagine some kind of extrapolated arguments about project scope
issues that would not be completely laughable, but you haven't really
presented any of those. As is, what you're saying just does not form an
argument that could be taken seriously at all.


 The criticisms of Upstart's event model in the systemd position
 statement simply do not make sense to me.  Events model how things
 actually happen in reality; dependencies are artificial constructions on
 top of them, and making them work requires the plethora of different
 directives in systemd (e.g. Wants, which is sort of a non-depending
 dependency) to avoid blocking the boot process on a single failing
 service.

Dependencies are the natural way to express what people know about the
system and what they need. Events are the internal implementation
details of what the machine does to make it happen.

I want task X started, and it needs task Y is what people express.
Start Y, and when Y is ready, start X are the compiled
implementation instructions to achieve the higher-level goal.


-- 
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/1388464464.3938.363.camel@glyph.nonexistent.invalid

Bug#727708: upstart and upgrading from sysvinit scripts

[Uoti Urpala]

On Sun, 2013-12-29 at 01:10 -0800, Steve Langasek wrote:
 However, I think this gets to the heart of why upstart upstream has avoided
 ever recommending the use of socket-based activation.  There are some fairly
 fundamental problems that basically halted development of socket-based
 activation in upstart (beyond merging of Scott's original implementation,
 which is rudimentary, as has been noted), and a look at systemd usage on
 Fedora led me to believe that systemd had not overcome these problems at
 all.

As far as I can see, what you're saying here is 100% based on
misconceptions only, and has no connection to any real issues
whatsoever.


 If I'm not mistaken (no references to hand - sorry), systemd upstream has
 claimed in the course of discussions on debian-devel that lazy activation is
 not the purpose of socket-based activation, and that using socket-based
 activation does not require you to pay the service startup penalty at the
 time of first connection.

Yes, this is true. If you have a daemon configured to always start, and
then add a .socket unit for socket activation, this does not in any way
STOP the daemon from starting!

Any mechanism that directly starts a .service will continue to do so
regardless of the existence of a .socket. What a .socket adds is that
you can have the socket active while the service is inactive, and in
this state an incoming connection to the active socket will trigger
start of the service. Other services which make requests through the
socket can depend on the .socket only (as opposed to directly depending
on the .service) to allow this state.


 On Fedora 20, after enabling the sshd and rsync service+socket units (both
 installed but disabled by default on Fedora per their policies on running
 services out-of-the-box) and rebooting, I find that both port 22 and port
 873 are bound by pid 1.  Only upon connecting to the socket does systemd
 actually spawn the server (in the case of sshd, it spawns it as 'sshd
 -i', so has to start up the server anew on each connection; in the case of
 rsyncd, the .service definition is completely incompatible with socket-based
 activation and any attempt to connect results in the rsyncd.socket unit
 landing in a 'failed' state).

Assuming this is an accurate description, it sounds like an intentional
decision for ssh and a bug in rsyncd (as Josselin already said).


 If what one is trying to accomplish here is to provide a replacement for
 inetd, then this is perfectly sufficient.  But if one is trying to use
 socket-based activation for the claimed purpose of ensuring service startup
 ordering without the need to declare explicit dependencies, then you must
 accept the penalty of lazy activation - which is almost never acceptable in
 a server context (where the purpose of the machine is to run the services
 that you have configured, and they should therefore not be started lazily),
 and suboptimal even in a client context (since not starting services that
 are on the critical path for boot until the client requests them will
 potentially lead to a significant boot-time slowdown, if all the services
 are doing this).

As above, your belief that systemd would force lazy activation has no
basis in reality that I can see.


 As far as I've been able to tell, the only solutions that would allow
 non-lazy socket-based-activation of services in systemd all introduce
 significant boot-time races, whereby it is no longer assured that systemd
 will bind to the socket (and passing the socket information via the
 environemnt) before starting the service.  Indeed, when I looked at this
 problem on an earlier version of Fedora, I found what I believe to be a
 latent security problem in the cups units, because it was nondeterministic
 whether the service would start with sockets passed from systemd, or a
 different set of sockets as defined in the cups config!
 
 When I mentioned this to Lennart at DebConf this year, his response was that
 cups was special.  Well, after further investigation, I don't think it's
 true that cups is special.  I think systemd socket-based activation is snake
 oil, that does not do what was promised without introducing hidden
 trade-offs which no one has been forced to acknowledge because too few
 developers are making use of this feature today to expose the integration
 problems.

If foo.service has Requires=foo.socket, then on general principles it
would sound like a very obvious bug if the service ever starts without
foo.socket active. I'd like to hear of some evidence of such a bug
before taking it seriously. And even if such a bug somehow existed,
fixing it should be a straightforward bugfix.


-- 
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/1388336133.3938.267.camel@glyph.nonexistent.invalid

Bug#727708: upstart and upgrading from sysvinit scripts

[Uoti Urpala]

On Sun, 2013-12-29 at 10:37 -0800, Steve Langasek wrote:
 It's quite possible that I am doing something wrong, but I don't think this
 is it.  Each of the .service units in question already had
 'WantedBy=multi-user.target', and each of the .socket units had
 'WantedBy=sockets.target'; on Fedora these were all disabled by default (to
 avoid any open ports by default), but upon enabling both the service and
 socket units, I get the behavior described.
 
 I was seeing the same behavior with the lbcd package in Debian, but it turns
 out this is due to the 'mutli-user' typo in lbcd.service.  Once I've fixed
 this (and created the proper 'enabled' symlink), I do see the lbcd process
 being started at boot.  So that much does seem to work as described, on
 Debian.  I'm not sure what to make of the Fedora setup, then, because other
 services that are linked into /etc/systemd/system/multi-user.target.wants do
 start up at boot, but neither sshd nor rsyncd is started when the .socket is
 enabled.

Enabling .socket is only supposed to start the socket, and the daemon
only if a connection arrives. If you want the daemon to start
unconditionally, you should enable the .service, not just the .socket.

   In that case, my concern is a different one - how can anyone claim
 that systemd's socket activation is ready for prime time if even a service
 as important as sshd hasn't been debugged in Fedora, one of the flagship
 adopters of systemd?

What makes you think it is buggy? So far I have seen no clear indication
of any bugs, only use of per-connection daemon instances which you
didn't like. And even if there were bugs, it is fairly easy to imagine
how an ssh maintainer could break it in one release independent of any
systemd issues.


   (BTW, there's also both an sshd.service and an
 sshd@.service here, adding to the confusion.  I've attached all of the sshd
 units in case you want to look at them.)

Those look like there are alternative units for a persistent daemon and
a per-connection daemon used with an Accept=true socket. The
sshd.service one is persistent and does not use socket activation. The
sshd@.service is a per-connection one instantiated for each connection
to sshd.socket. You're probably supposed to enable either sshd.socket
(for per-connection daemons) or sshd.service (for a persistent daemon).


 This still leaves the concern I have about start-time races.  According to
 systemd.unit(5), using 'Requires=', as Uoti suggested to Russ, does *not*
 guarantee ordering:

but as I said at the end of
https://lists.debian.org/debian-ctte/2013/12/msg00206.html
there's an automatic Before: dependency created from sockets to
identically named services. So it shouldn't be necessary to give it
explicitly.

 In my earlier investigations (which were on Fedora 17, IIRC), I definitely
 found races where a service configured with a corresponding .socket would
 *sometimes* start at boot time before the socket is bound, causing it to
 fall back to its own config file and binding to its own sockets... which

I'm not sure if some parts of the behavior have differed before. At
least the code setting the default dependencies has not stayed exactly
the same; I didn't try to find out whether the behavior has actually
changed.

Even with current systemd you could probably produce such behavior with
suitable configuration - at least if you do NOT add a Requires= and
create an early boot service that can run before sockets.target.

 diligently keeping the two implementations in sync.  Since
 LISTEN_FDS/LISTEN_PID is the defined API for systemd passing the socket
 information to the service, for systemd to ever fail to pass this socket
 information, resulting in the service deciding that it's not *actually*
 running under systemd and should fall back to a different mode, is
 potentially a very serious problem.

If you want to make sure your service never tries to start without
socket activation, it should have Requires=foo.socket; none of the
default relations are strong enough to strictly prohibit starting
without a socket. I think at least the case where creating the socket
fails and admin manually says systemctl start foo.service would always
start the service without a socket otherwise.


-- 
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/1388347941.3938.293.camel@glyph.nonexistent.invalid

Bug#727708: systemd vs. binfmt-support

[Uoti Urpala]

On Sun, 2013-12-29 at 14:02 +, Colin Watson wrote:
 I was referring more to Tollef's position, really.  Debian systemd
 maintenance ought to take into account matters of Debian integration,
 which includes whether it fits well into best-of-breed Debian practice.
 
 If it's easy enough to override, then given that we have a better
 implementation in Debian then we should simply continue to use it.

I think Tollef's post was a reasonable first reaction at least -
minimizing Debian-specific code (even if it's used somewhere else,
Tollef was apparently not aware of that).


  I think this has been proven false by experience - systemd has innovated
  a lot in things where smaller projects were stagnant. And there's a
  fairly clear reason why this would be so: something like binfmt-support
  is too small a unit for independent development, both to design
  independently and to sell to every user individually.
 
 It's simply not true that it's too small a unit for independent
 development (what on earth gives you the authority to pronounce on this,

  Binfmt support is not that complex a task in itself. In practice, a lot
  of the usability will depend on consistency with other system parts.
  Designing APIs for it only is too narrow a view; you need to consider
  other tools, and if you can do better, then it's quite likely you should
  change the other tools too (things like adding udev rules etc).
 
 However, I've been thinking about this for rather a long time, and I'm
 actually quite familiar with the design issues.  binfmt-support is
 specifically designed to be suitable for distributions (not just Debian)
 shipping binfmt integration; in particular I have put much more effort
 than systemd has into how it fits into packaging.

I'm not saying that it would be too small to do anything useful with.
But is it really different enough from other cases of setting kernel
parameters to justify a completely unique approach? My gut feeling is
that either binfmt-support should be closer to other tools, or the other
tools should be changed to take into account lessons from
binfmt-support.


  Convincing every distro builder out there individually that your binfmt
  support code is best wastes effort, both yours and theirs. It's more
  efficient to have systemd upstream decide what is a reasonable default
  implementation, and then have only people with specific needs or
  opinions change it.
 
 This sounds very much like an argument from authority, and I'm afraid I
 don't subscribe to it.  I don't consider my effort wasted, and I don't

It's not an argument from authority - I'm not saying that
implementation is best, because systemd upstream chose it; in fact I
was not trying to argue the benefits of any implementation. What I meant
was that I think it's beneficial to have default choices, and that
choices made by systemd upstream are more likely to be correct than the
collective average of people who would make such choices individually
(plus everyone making individual choices would use more effort).
Accepting this as true does not require accepting systemd upstream as an
authority whose opinion would automatically decide an issue.

It's also beneficial to use shared standard methods as much as possible,
and systemd upstream is probably about as close as you'll get to a
shared standard in an actively developing area in practice (I certainly
don't believe that any committee could do better). I think avoiding
unnecessary deviations from the shared code has benefits similar to
doing things according to POSIX when possible; that does not mean that I
would consider POSIX authors to be authorities who could dictate how
things should be done.


-- 
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/1388356109.3938.324.camel@glyph.nonexistent.invalid

Bug#727708: systemd vs. binfmt-support

[Uoti Urpala]

On Thu, 2013-12-26 at 21:42 +, Colin Watson wrote:
 On Thu, Dec 26, 2013 at 08:49:11AM +0100, Tollef Fog Heen wrote:
  In this particular case, as you write, I hadn't really given it any
  consideration before, but what I think would make sense is to extend
  systemd to support the same interface as binfmt-support and then people
  who don't use systemd can use binfmt-support and those who use systemd
  (on Debian or elsewhere) can use systemd-binfmt.  I'm guessing the

 afraid it leaves me rather cold, though.
 
 The first reason is, I suppose, rather selfish: I've been working on
 this on and off for fourteen years and it seems a bit rude for systemd
 to turn up and declare that it's now the standard on the strength of an
 underpowered implementation, without even mentioning it to me (I'll
 accept that this is irrational since the systemd authors probably
 weren't aware of the prior art, but it's certainly my gut reaction).  I

I don't think systemd authors have made any declarations about binfmt in
particular. The only thing they've actually done is add a very simple
implementation (src/binfmt/binfmt.c, less than 200 lines of code, much
of it argument parsing). I consider having a basic implementation to be
a useful batteries included feature: systemd supports lots of
different setups from embedded to desktop, and it's useful to have at
least a basic implementation ready when building a system. It's easy
enough to override if you want something different. Thus I consider any
opinions saying systemd should not include a tool for setting binfmt, or
that adding it was somehow objectionable behavior, to be wrong. Whether
it would be preferable for the tool to support more complex
functionality is another question.


 suppose I'm concerned what the incentive is for people to innovate on
 this sort of thing in the future (and binfmt-support absolutely was
 innovative in terms of making the packaging of the underlying kernel
 technology trivially accessible) if they can be steamrollered at any
 time; in the long term I have more faith in the flexibility of many
 small projects than one big one.

I think this has been proven false by experience - systemd has innovated
a lot in things where smaller projects were stagnant. And there's a
fairly clear reason why this would be so: something like binfmt-support
is too small a unit for independent development, both to design
independently and to sell to every user individually.

Binfmt support is not that complex a task in itself. In practice, a lot
of the usability will depend on consistency with other system parts.
Designing APIs for it only is too narrow a view; you need to consider
other tools, and if you can do better, then it's quite likely you should
change the other tools too (things like adding udev rules etc).

Convincing every distro builder out there individually that your binfmt
support code is best wastes effort, both yours and theirs. It's more
efficient to have systemd upstream decide what is a reasonable default
implementation, and then have only people with specific needs or
opinions change it.


 The second is that it seems like makework for the sake of aggrandising
 systemd.  systemd isn't bringing anything new to the table here; right
 now it's just exposing the raw underlying kernel interface in the form
 that's existed since 1997, and in a way that (AIUI) only works properly
 at boot time rather than doing sensible things when packages are
 installed or removed.  Of course you can put all the pieces together,
 but that was the point of binfmt-support.  This is straight
 wheel-reinvention and it seems like a total waste of everyone's time.

As above, I certainly disagree about including binfmt code being a waste
of time; having to look at a separate project to get any support at all
for something so simple would be a waste of time. Most likely supporting
more features from binfmt-support would be an improvement, but that
doesn't make having the current code a negative thing.

I'm not sure whether including exact binfmt-support functionality would
have been a reasonable option for systemd (GPL vs LGPL probably
precludes code copy). At least the API would not be very consistent with
other tools.


-- 
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/1388289390.3938.208.camel@glyph.nonexistent.invalid

Bug#727708: upstart proposed policy in Debian [and 1 more messages]

[Uoti Urpala]

On Sat, 2013-12-21 at 08:49 -0800, Russ Allbery wrote:
 Tollef Fog Heen tfh...@err.no writes:
  sd-daemon.c is also intentionally designed to not have dependencies on
  the rest of the systemd source and to be portable to non-linux
  architectures too (but basically just stubs then) just so people can put
  the file in their source and not have to fiddle with checking for
  libraries and such if they find that tedious.
 
 I agree with Ian's dislike of this approach.  We try to avoid embedded
 code copies, and I'm not sure why this would be an exception.  Yes, the
 code is fairly simple and hopefully doesn't contain (for example) security
 vulnerabilities, but it's possible to find bugs in just about anything.
 Updating numerous copies of that code is not appealing.

I don't see why that should be considered a particularly significant
downside though. Copies are usually worse than shared code, but not
really worse than everything having a custom implementation. At least
implementing sd_notify() support with a code copy should be considered a
significant improvement over a daemon that always runs custom
double-forking code.

BTW it's worth noting that in the typical daemon case where readiness
means the listening socket is ready to accept requests, the right way to
convert the daemon to a new API is to use socket activation, which
removes the need for separate start-up completion notification. Thus the
need to use sd_notify() for this purpose should be the exception rather
than the rule. This means that daemons which would use libsystemd-daemon
for startup notification and nothing else (and would thus be potential
candidates to abuse SIGSTOP) should be rare.


-- 
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/1387662984.3938.143.camel@glyph.nonexistent.invalid

Bug#727708: systemd jessie - jessie+1 upgrade problems

[Uoti Urpala]

On Wed, 2013-12-18 at 13:34 +0200, Adrian Bunk wrote:
 On Tue, Dec 17, 2013 at 06:02:50PM -0500, Sam Hartman wrote:
  I'm confused, when I hear you say that this risk is unique to the
  systemd option and not shared by other options.  I would understand that
  statement if we thought we could avoid systemd entirely.  It sounds like
  we may be able to avoid systemd as pid 1 but systemd is very likely to
  play an important role in the Debian desktop storpy even if we adopt
  another pid 1.

 Thanks for the explanation, and apologies to Josselin and Russ that
 I completely misread their point regarding udev:
 
 I was misreading that as referring to the headaches udev had caused in 
 the past for Debian upgrades, not that the systemd udev might be the 
 cause of future upgrade headaches.
 
 But I do not buy this We already switched to systemd as upstream of 
 udev, so we also have swallow the rest of it:
 
 When not using systemd as pid 1, that risk would be confined to the 
 parts of systemd Debian would be using (currently only udev).

I think you still misread the argument: IMO it's clear that it
considered more than udev as likely to be required, even if udev is the
only one in current Debian. So if you disagree, you should at least
address the question of why you believe udev will stay the only one.


  At some level, we also need to be community players.  Since upgrade
  stability is important to us, we should advocate for it in open-source
  projects that we depend on.  On the flip side, if enough of the rest of
  the community after having carefully considered our arguments decides
  that our desire for stability is too expensive, perhaps we need to
  reconsider our position.  I hope we don't need to do that, but sometimes
  when enough of the rest of the world disagrees with you, you need to
  move on.


 systemd upstream only reluctantly supports the option to have a separate
 /usr (as currently mandated by Debian policy), and I would not be 
 surprised if that gets dropped any time if it becomes an obstacle
 for development of any part of systemd.

You're mixing two separate issues (or at least not clearly indicating
which one you're talking about). Systemd fully supports having a
separate /usr partition, and that is in no way deprecated AFAIK. What
has changed compared to old practice is that /usr needs to be mounted
together with root (requiring initramfs if you have a separate /usr;
where you had mount / before you now have mount / and /usr). Whether
the old way of later /usr mounting could keep working with any other
init either is questionable.

Then there is the move of binaries from /bin to /usr/bin, which does
have some backwards compatibility logic for different paths in systemd.
This is not directly connected to /usr being a separate partition or not
(but having everything in /usr/bin obviously requires /usr mounted
early). Does someone in Debian seriously oppose this move as a long term
goal?


 And now you bring up the point that Debian should reconsider the 
 lenght of it's release cycles if systemd upstream decides to not
 support upgrades between distribution releases as far apart as Debian's. [3]

I don't think anyone said that. Nobody talked about long release cycles
not being supported, and nobody said that upgrades would not be
supported either. However, supporting upgrade from the old release
does not equal things like being able to run the new userland on the 3+
year old kernel from the previous release.

A development model where you have to wait 3+ years before you can have
hard dependencies on the new features you write now is obviously very
problematic. IMO such restraints should never be taken for granted;
upgrade schemes should always be planned to at least make it possible to
have newer dependencies without too much trouble.

In the kdbus case, systemd upstream already mentioned the possibility of
shipping kdbus as a new module for older kernels. More generally, you
can have solutions like applying some upgrades at boot rather than
trying to switch parts from under a fully live system. This does still
count as fully supporting upgrades.


-- 
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/1387372219.3938.46.camel@glyph.nonexistent.invalid

Bug#727708: systemd socket activation protocol rationale

[Uoti Urpala]

On Sat, 2013-12-14 at 21:45 +, Ian Jackson wrote:
 I've just been reading sd_listen_fds(3).  It's vaguely similar to
 upstart's socket activation protocol.  It supports multiple sockets
 (which is obviously important).
 
 But I have a few questions about the details:
 
 Why do only some of the environment variables start SD_ ?
 We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START.

You misread it: there is no environment variable SD_LISTEN_FDS_START.
The API defines the start value as the constant 3. There is a
corresponding #define in sd-daemon.h, but it is not communicated at
runtime.


 What is the rationale behind the use of the LISTEN_PID variable and
 the pid check ?  It seems to me that at the very least this might make
 it hard to wrap up a socket-activated daemon in a shell script.

To ensure that the environment values are never accidentally inherited
by any child process.


-- 
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/1387060605.3938.6.camel@glyph.nonexistent.invalid

Bug#727708: systemd (security) bugs

[Uoti Urpala]

On Mon, 2013-12-02 at 15:32 -0800, Don Armstrong wrote:
 On Tue, 03 Dec 2013, Josselin Mouette wrote:
  Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit : 
   Josselin Mouette j...@debian.org writes:
   
There are two implied assumptions here: 
  * that the same people are developing all components; 
  * that develolpers have the same attention to code quality and
security in all components they work on.
   
I don’t think either of them applies to systemd.
   
   Right, this succinctly captures one of my biggest concerns about systemd.
  
  Could you please elaborate on this concern? Is it about the large number
  of developers, or about the fact they treat important pieces of code
  more carefully?
 
 Projects which have multiple components, each of which has different
 security/interface surfaces without stable defined interfaces, can lead
 to problems when one set of developers doesn't understand the security
 implications of the parts that they do not work on.
 
 The combination of components into a single monolith is sometimes
 necessary, but it's not clear that it is so in the case of systemd.

IMO single monolith is bad terminology - to me that sounds something
like everything in a single process, while the systemd components are
quite modular.

Not clear it's necessary seems like an overly negative attitude. There
doesn't seem to be much disagreement about the fact that many of the
systemd components are very useful and would be used even with a
different init. The above security considerations seem purely
theoretical, with no sign that they'd be an issue with systemd in
practice. And IIRC no other actual technical problems resulting from
developing the components together have been brought up in this thread
either. So why should it be done any differently, when this way appears
highly successful?


-- 
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/1386051464.1822.19.camel@glyph.nonexistent.invalid

Bug#727708: systemd (security) bugs (was: init system question) [and 1 more messages]

[Uoti Urpala]

On Fri, 2013-11-29 at 12:37 +, Ian Jackson wrote:
 Uoti Urpala writes (Bug#727708: systemd (security) bugs (was: init system 
 question)):
  My guess is that most people do not consider that exciting or really
  care - thinking of system states in terms of runlevels is mostly
  obsolete, and the flaws do not bother many people in the cases where
  backwards compatibility is still needed.
 
 Statements like this are part of what make me think this might be a
 fundamental problem.  When a systemd proponent tells me that a
 particular use pattern is unimportant or wrongheaded, I tentatively
 infer that systemd cannot support it properly.

At least here this logic led you to the wrong conclusion, so you might
want to reconsider it.

 It seems to me that the difficulties with the runlevel emulation are
 likely to affect other similar use patterns too.  The problems don't
 seem specific to the nature of runlevels.  Perhaps they are specific
 to the way runlevels are emulated by systemd but in that case that
 emulation should surely be fixed.

The issue was legacy runlevel changes being simply mapped to isolate
new_runlevel, which does not have quite the same semantics as sysvinit
runlevel changes (most importantly, it stops everything not in the
new_runlevel target, without limiting to only things that were part of
original runlevel target). There's no reason why the set of services to
stop could not be calculated in a way closer to sysvinit semantics. But
there's little reason to deal with runlevels at all when using
systemd, and it seems most people don't. So while the backwards
compatibility support could be improved (probably rather easily), I
think it's clear why this has not been a priority for either developers
or users.


 More importantly it is one which is exploitable only as a consequence
 of the questionable design decision to expose pid 1 to ordinary users.

I think there are good reasons to allow querying status directly. One
sanity check that IMO should be kept in mind for perspective when
considering any even one DoS issue in PID 1 is a catastrophe arguments
is that Debian will always require running a kernel, and there have been
lots of DoS or worse issues there. Unless you expect the majority of
Debian users to move to minimal microkernels in the near future, there
is little basis to demand an absolutely minimal init process when the
kernel contains much more code in a more critical role.

The same applies to this:
 and is being touted as the single systemwide manager for security
 features like cgroups !

Parts of the implementation for this are on the kernel side, parts on
the systemd side. I see no reason to think that the systemd side would
be the more problematic one.


-- 
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/1385755769.13584.51.camel@glyph.nonexistent.invalid

Bug#727708: systemd (security) bugs (was: init system question)

[Uoti Urpala]

Ian Jackson wrote:
 It isn't always 100% clear to me from reading these which of them
 apply to systemd's init replacement.  But reading the systemd debate
 page makes it clear that the other components in the systemd upstream
 package are seen by systemd proponents as part of their offering, and
 indeed reasons to pick systemd.

Yes, the other tools that systemd provides and enables are part of its
usefulness, so it is appropriate to look into their quality.


 I should say that it is hard to write code with no security bugs at
 all.  But I think our benchmark for security bugs in our init system
 ought to be very few, particularly if we are making a specific
 implementation effectively mandatory.  And I don't think I would like
 to accept justifications (for a large bug count) along the lines of
 but systemd does so much more; I think the security bugs that come
 with a large codebase, or having more functionality exposed to
 ordinary users, are a direct and very relevant downside to such a
 large codebase or large attack surface.

But this, I think, is completely wrong. You shouldn't count bugs from
other tools included with systemd against its core init functionality or
vice versa. If for example systemd and coreutils came from the same
source package, that should be allowed as many bugs as the current two
separate source packages, not less.

Most of the separate functionality is optional. It's likely that Debian
would want to use it, but then Debian would want that functionality with
other init systems too (or miss it). The most appropriate comparison is
whether it's possible to have similar functionality with less bugs
(whether provided with init system or completely independently). As far
as I can see, for most functionality there are no such alternatives.

At least Upstart, and likely other alternatives to systemd also, would
still use forked versions of at least logind and possibly other tools
originating from systemd. Such forks are worse for security than using
the original systemd one. Thus the fact that logind is developed with
systemd should count in favor of systemd, not against it.

Also, systemd is the system under the most intense scrutiny for security
and other issues, so it's not easy to compare bug counts with
alternatives - alternatives likely have a significantly larger portion
of issues undetected.


 Here are a couple of exciting snippets:

 https://bugzilla.redhat.com/show_bug.cgi?id=708537
 
   Problems with runlevel emulation doing mad things.  It isn't clear
   to me whether this bug is a symptom of a fundamental problem with
   systemd's state-based dependency model, or whether it's simply a

I think it's completely obvious that there is no fundamental problem.
I wonder what could make you consider it a possible symptom of one.

   missing feature or perhaps even wrong default configuration.  But
   the bug has been open for some time.

My guess is that most people do not consider that exciting or really
care - thinking of system states in terms of runlevels is mostly
obsolete, and the flaws do not bother many people in the cases where
backwards compatibility is still needed.


-- 
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/1385668823.13584.28.camel@glyph.nonexistent.invalid