subject:"Re\: systemd .service file conversion"

Salvo Tomaselli wrote:
  You have the context wrong here. considering systemd as a default init
  is too vague.
 Wikipedia says: A default, in computer science, refers to a setting or a 
 value 
 automatically assigned to a software application, computer program or device, 
 outside of user intervention.
 
 What's vague about that?

It's the meaning of considering that was too vague, not the meaning of
default. Considering whether systemd is a suitable choice for default
init vs considering whether current Debian systemd packages are in a
state where they should be made the default, and so on.


  Yes, there is integration work left. But that's really about the
  question is Debian ready to switch all user machines to systemd right
  now using the current packages?, and I think nobody would answer yes
  to that
 Good so that was exactly my point: let's have this thread when systemd is a 
 production ready alternative.

Your error is that you mix up the status of systemd and the status of
systemd Debian integration. Systemd is a production ready system the
same way Apache is a production ready system. Systemd Debian integration
is not yet complete to that degree (not that it would be particularly
bad; people don't have to be insane to already use it on production
servers).


  He was confusing what were likely integration issues with
  what would be more fundamental issues with systemd itself (that would
  make it less desirable to do the integration work and switch at all),
  and I tried to explain the difference.
 I didn't say it has fundamental architectural flaws that can't be addressed, 
 I 
 said it should be care of the people who want it as default to take care of 
 the flaws and make it a viable alternative before talking about it.

Most likely the problem you encountered was no flaw of any kind in
upstream systemd. It could have been a flaw Debian systemd setup, or a
flaw in another package entirely that just happened to trigger under
systemd. The latter kind aren't even particularly the responsibility of
people working on systemd support, even if they do need to be fixed for
systemd Debian integration.

So, to sum it up: Upstream systemd is ready for production and suitable
to be chosen as the default Debian init. Current Debian systemd packages
are not ready to be made the default for all users; nobody is claiming
they would be. Encountering some shallow problems is expected as more
users test them, and this is pretty much unavoidable while integration
work is still going on. You mixed up these two things (you also talked
about use in Fedora, which obviously says nothing about Debian
packaging). It's also obvious your time figures were completely made up
(a few years to mature).



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1370113345.3628.250.camel@glyph.nonexistent.invalid

Re: systemd .service file conversion

2013-06-01 Thread Ondřej Surý



Ondřej Surý

On 1. 6. 2013, at 11:59, Marc Haber mh+debian-de...@zugschlus.de wrote:

 On Fri, 31 May 2013 16:33:22 +0200, m...@linux.it (Marco d'Itri) wrote:
 On May 31, Jeff Epler jep...@unpythonic.net wrote:
 The idea that somehow users of non-linux kernels don't matter or don't
 even exist as debian users is one of the most frustrating bits of this
 whole thread.
 I'm sorry for the three kfreebsd users, but sometimes reality sucks.
 Pretending that their needs are as much important as the needs of the 
 99% of Debian users who use Linux does not make it true.
 
 Before saying things like that, please file a GR removing the
 universal from Debian's claim.

Please do not troll. It's neither constructive nor helpful.

We have removed archs from release archs and moved them to ports and nobody 
claimed we are less universal. (And my strawman argument could be some like: if 
we don't support some-obscure-kernel then we are not universal...)

What the project needs to do is to define a set of the reasonable criteria for 
inclusion/exclusion of a release kernel.

O.

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/f0497922-b91a-4b8b-b7d8-54abd4881...@sury.org

Re: systemd .service file conversion

2013-06-01 Thread Ondřej Surý

On 1. 6. 2013, at 16:48, Marc Haber mh+debian-de...@zugschlus.de wrote:

 On Sat, 01 Jun 2013 12:42:33 +0200, John Paul Adrian Glaubitz
 glaub...@physik.fu-berlin.de wrote:
 What's the point in doing that work
 when, in the end, hardly anyone is using it?
 
 Freedom. It is not free to take away freedom just because too few
 people have chosen to exercise freedom.

And where is my freedom to ignore kfreebsd? It's a release arch, so bugs 
against kfreebsd are RC. (Not that I want to ignore them.)

Please stop this rherhorical excercise on degrees of freedom and let's focus on 
real work and real world.

O.

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/d74f3888-4816-4e07-9793-9b17cec42...@sury.org

Re: systemd .service file conversion

2013-06-01 Thread Wouter Verhelst

On 30-05-13 22:36, Uoti Urpala wrote:
 Russ Allbery wrote:
 Uoti Urpala uoti.urp...@pp1.inet.fi writes:
 Marc Haber wrote:
 And it is still completely inferior even to dpkg-conffile handling,
 which has huge wishes left open as well.

 False. The message you replied to already listed advantages over
 dpkg-conffile handling. This was also already discussed before:
 https://lists.debian.org/1336580040.28230.9.camel@glyph.nonexistent.invalid

 We've had this discussion a lot.  There is an ongoing technical
 disagreement of opinion about the tradeoffs.
 
 While there is room for reasonable disagreement about the relative
 benefits of different configuration setups, completely inferior even to
 dpkg-conffile handling is not part of any reasonable disagreement. That
 claim is simply false.

No. That claim is an expression of opinion. Marc believes that
dpkg-conffile handling is superior to having defaults in /usr/lib (or
thereabouts) and only overriding those from /etc. You disagree with him,
which is certainly your right. However, you are neither more nor less
correct than Marc; you are both correct. That's the problem about
opinions: they're not technical.

FWIW, I happen to agree with Marc. Having everything in /etc makes it
*much* clearer what the actual current configuration is; it also means
that if the defaults change on upgrade, your environment doesn't
suddenly start acting differently or inconsistently.

Both are reasons (though certainly not the only ones) why upgrading
Debian is feasible (and the rule rather than the exception), while
trying to upgrade a RedHat machine is only for the crazy.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51aa4f05.4090...@debian.org

Re: systemd .service file conversion

Marc Haber wrote:
 On Sat, 01 Jun 2013 12:42:33 +0200, John Paul Adrian Glaubitz
 glaub...@physik.fu-berlin.de wrote:
 What's the point in doing that work
 when, in the end, hardly anyone is using it?
 
 Freedom. It is not free to take away freedom just because too few
 people have chosen to exercise freedom.

Why would kFreeBSD particularly matter for freedom? As opposed to any
other random piece of software?

Debian regularly removes old buggy packages that few people use. Are you
saying that is wrong, and for the sake of freedom people should be given
the ability to keep installing them even if few actually want to? If
not, what makes kFreeBSD special so that it is more about real
freedom?

Do you claim that the existence of kFreeBSD is likely to somehow make
the world a better place for someone in the long run? I myself believe
that working on software that actually gets used is beneficial on
average, while I think the world would be a better place if kFreeBSD had
never been started at all - the negative effects on other Debian
development outweight any benefits.

Or is it about some ideal notion of freedom you have? I don't think
anything in common free software philosophy at least would imply that
kFreeBSD is important.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1370116640.3628.277.camel@glyph.nonexistent.invalid

Re: systemd .service file conversion

2013-06-01 Thread Stephan Seitz


On Sat, Jun 01, 2013 at 09:44:05PM +0200, Wouter Verhelst wrote:

FWIW, I happen to agree with Marc. Having everything in /etc makes it
*much* clearer what the actual current configuration is; it also means
that if the defaults change on upgrade, your environment doesn't
suddenly start acting differently or inconsistently.


Not only this, you see if this service can be configured via /etc by 
looking in /etc for fitting files. How should I know that I have to look 
for configuration files in some lib directory and know to which place 
I have to copy them in /etc?


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: systemd .service file conversion

2013-06-01 Thread Svante Signell

On Sat, 2013-06-01 at 22:57 +0300, Uoti Urpala wrote:
 Marc Haber wrote:
  On Sat, 01 Jun 2013 12:42:33 +0200, John Paul Adrian Glaubitz
  glaub...@physik.fu-berlin.de wrote:

 Why would kFreeBSD particularly matter for freedom? As opposed to any
 other random piece of software?
 
 Debian regularly removes old buggy packages that few people use. Are you
 saying that is wrong, and for the sake of freedom people should be given
 the ability to keep installing them even if few actually want to? If
 not, what makes kFreeBSD special so that it is more about real
 freedom?

Both kFreeBSD and Hurd have contributed to multiple upstreams suddenly
realizing they are creating buggy and non-portable software. This is a
very important issue wrt software quality, and should be counted as one
major reason to continue to support non-linux systems.

Additionally, Debian is about software freedom, not about lock-in of
customers as for commercial vendors. Debian is promoting software
freedom, if they stopped doing that then the whole idea of Debian would
be lost (and should be discontinued, letting RedHat, Ubuntu, et al take
over the whole (Linux) market). 

Plan9 and minix go away, you are only clutter ;)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1370122675.6337.14.camel@PackardBell-PC

Re: systemd .service file conversion

2013-06-01 Thread Salvo Tomaselli

In data sabato 01 giugno 2013 22.02.25, Uoti Urpala ha scritto:

 So, to sum it up: Upstream systemd is ready for production and suitable
 to be chosen as the default Debian init.
Can you back up your claim somehow?

 You mixed up these two things (you also talked
 about use in Fedora, which obviously says nothing about Debian
 packaging). It's also obvious your time figures were completely made up
My figures come from the fact that any project with 2 new versions per week 
can't be called mature. Source: download page of systemd.

You don't have any figures.

 (a few years to mature).
In that point I was expressing a personal opinion, the full quote being: I 
like the approach it has, and in a few years I believe it has potential, that 
was not a calculated figure.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1891912.vhzPeMDqoA@hal9000

Re: systemd .service file conversion

Wouter Verhelst wrote:
 On 30-05-13 22:36, Uoti Urpala wrote:
  While there is room for reasonable disagreement about the relative
  benefits of different configuration setups, completely inferior even to
  dpkg-conffile handling is not part of any reasonable disagreement. That
  claim is simply false.
 
 No. That claim is an expression of opinion.

Calling something an opinion does not make it valid. It may be
someone's opinion that 1+1=3, but that's simply false whether it's an
opinion or not.


  Marc believes that
 dpkg-conffile handling is superior to having defaults in /usr/lib (or
 thereabouts) and only overriding those from /etc.

To begin with, that's comparing apples to oranges. You're comparing the
behavior of the packaging system on upgrades to the behavior of the
application in use. The most plausible way I can construct something
reasonable-sounding from your text is the comparison application
default config in /etc and user modifies existing files to configure;
dpkg-conffile handling of those files on package upgrades vs
application default config in /usr/lib and user can add files to /etc
to override everything or just particular options; package upgrades
always simply update files in /usr/lib to new version with no other
special action for configuration. Now you could have different
reasonable opinions about the tradeoffs in these two cases, though
completely inferior would still be exaggerated hyperbole at best. But
this comparison does not match the original context of the discussion,
where application behavior by itself was criticized. Obviously the
application is not responsible for what Debian packaging does on
upgrades, and the package upgrades could easily behave differently.

If you want to post your opinion about a controversial topic, at least
you should do a better job of phrasing exactly what it is that you're
claiming. If people don't agree to begin with, you shouldn't expect them
to make all the same implicit assumptions you do. And here it seems more
like sloppy thinking where even you yourself hadn't thought through your
assumptions.

Also, these issues were already covered in the thread a year ago (and
your post doesn't look like you'd have understood the arguments there
but disagreed).



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1370124763.3628.310.camel@glyph.nonexistent.invalid

Re: systemd .service file conversion

Svante Signell wrote:
 On Sat, 2013-06-01 at 22:57 +0300, Uoti Urpala wrote:
  Debian regularly removes old buggy packages that few people use. Are you
  saying that is wrong, and for the sake of freedom people should be given
  the ability to keep installing them even if few actually want to? If
  not, what makes kFreeBSD special so that it is more about real
  freedom?
 
 Both kFreeBSD and Hurd have contributed to multiple upstreams suddenly
 realizing they are creating buggy and non-portable software. This is a
 very important issue wrt software quality, and should be counted as one
 major reason to continue to support non-linux systems.

I think this is the broken window fallacy. No doubt some related changes
involved improving upstream code, but then about any other changes could
have done the same. In general, finding things that could be improved is
very easy and does not justify significant effort unless it's for
specific things like bad security bugs.

And you didn't answer the question of what this has to do with *freedom*
at all.


 Additionally, Debian is about software freedom, not about lock-in of
 customers as for commercial vendors. Debian is promoting software
 freedom, if they stopped doing that then the whole idea of Debian would
 be lost (and should be discontinued, letting RedHat, Ubuntu, et al take
 over the whole (Linux) market). 

This again raises the same question. What does software freedom have to
do with kFreeBSD or Hurd? You imply that dropping Hurd would make things
less free. Why would it do that more significantly than dropping some
obsolete package nobody uses?



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1370126988.3628.322.camel@glyph.nonexistent.invalid

Re: systemd .service file conversion

2013-06-01 Thread Miroslaw Baran

On Sun 02 Jun 2013 01:12:43 Uoti Urpala wrote:

 Also, these issues were already covered in the thread a year ago (and
 your post doesn't look like you'd have understood the arguments
 there but disagreed).

Your quality advocacy work for upstart is almost as good as Rob Weir's 
incessant efforts to promote LibreOffice. Keep up the good work.

Sincerely,
– Jubal

-- 
Some people in this department wouldn't recognize subtlety if it hit
them on the head.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5559084.I9Cz6BGbWS@metatron

Re: systemd .service file conversion

2013-05-31 Thread Helmut Grohne

On Fri, May 31, 2013 at 01:44:12AM +0300, Uoti Urpala wrote:
 Steve Langasek wrote:
  I can't speak to other distributions, but in Debian, the systemd maintainers
  are in no position to decide that Debian will agree to rewrite its
 
 Focusing on position to decide seems less than constructive.

I believe that you are mistaking Steve's point here. His statement
appears merely factual to me. And that is what it is. Some of the paths
you were talking about are explained in the Debian policy as exceptions
to FHS, and clearly it is not individual maintainers to decide how to
change the policy.

 It makes a lot of sense to standardize those files across distributions.
 You don't seem to disagree with Debian following the FHS for example (or
 was your attitude to that our current paths work quite well already,
 thankyouverymuch too?). Why would custom /etc file locations be the
 very purpose of Debian's existence in a way that prohibits
 standardization, if other filesystem layout isn't?

Again you appear to have a difficult time getting the argument. The
purpose outlined was the integration work, not specific paths. Specific
paths are merely a tool to get there. They can change, but that requires
a lot of work and usually breaks tons of stuff. Indeed Debian is
adopting a number of things from different distributions. That is a hard
thing to do though, even for things that are already defacto standards.
For example adopting the required filename encoding from Fedora turned
out to be harder than expected (#701081). So given the work required to
change such an aspect, the ones who want the change need pretty good
arguments.

 If you think there is something actually wrong with the default choices
 currently used by systemd, a much more constructive approach would be to
 get that fixed across distros, rather than have Debian use a different
 custom layout. Note that standardizing on the current Debian locations
 across distros would not have been a good choice for the above two
 files, as they include the rather arbitrary /default/ path.

More often than not, there is no wrong with specific naming in
standards. It just happens that you have to pick one. Indeed systemd
appears to have come a bit late to the party and Debian has had a
standard long before. Arguably systemd could be the one opting to adopt
an existing standard. (Now this is of course false, because RedHat had
their own file name policy well before the invention of systemd.) This
is more true for the socket activation API that systemd could have
reasonably adopted from upstart, but chose not to do.

 If you oppose them just because they come from systemd upstream, well...

It appears to me that we are wading into baseless accusations and
personal attacks. I ask you to just skip such parts next time, because
they add no value to your arguments.

 Of course Debian can choose to use different locations/semantics for the
 files if there is some actual justification. But IMO it's completely
 reasonable for upstream to decide that they should not be the ones who
 bear the burden of maintaining the patches for any such distro-specific
 divergences.

systemd is a project that claims to do integration work. It clearly has
a big surface of interfaces with other projects. Otherwise it would not
be discussed that often and would be easily swappable for something
else. Given that systemd is developed at RedHat it appears obvious that
upstream is biased towards the standards RedHat uses (with a few
exceptions adopted from Debian and others). The incompatible socket
activation API is a prime example for this. So in this case I think
there is less reason to trust this particular upstream with our needs.
On the other hand I see little point in discussing this further, because
the Debian systemd maintainers are doing an awesome job.

Helmut


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531061654.ga29...@alf.mars

Re: systemd .service file conversion

2013-05-31 Thread Olav Vitters

On Thu, May 30, 2013 at 01:59:02PM -0700, Steve Langasek wrote:
 I can't speak to other distributions, but in Debian, the systemd maintainers
 are in no position to decide that Debian will agree to rewrite its
 system-level integration code (which works quite well already,

I meant more that:
- systemd coordinates across distributions via specific entry points
- those entry points either fully handle or discuss further or whatever
  is needed
- if you want differences between distributions, then systemd is not a
  good choice
- if you come late to the game, then obviously influencing things is
  more difficult

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531090940.ga4...@bkor.dhs.org

Re: systemd .service file conversion

2013-05-31 Thread Olav Vitters

On Thu, May 30, 2013 at 10:26:37PM +0200, Marc Haber wrote:
 Of course it won't. Upstream and Red Hat have shown many times that
 they just don't care.

I've already replied with various examples before refuting this.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531091036.gb4...@bkor.dhs.org

Re: systemd .service file conversion

2013-05-31 Thread Josselin Mouette

Le jeudi 30 mai 2013 à 22:25 +0200, Marc Haber a écrit : 
 Do you actually run a kernel other than Linux
 
 Actually no, but it is a pleasure to see Debian move towards this
 freedom with every new release. 

I disagree with this claim. The wheezy release for kfreebsd is a joke,
and we should end it with jessie unless there are real users.

 systemd would put this freedom farther away than it ever was.

Using a dysfunctional port to justify keeping improvement away from the
ports that our users actually run is, at best, sophistry.

If you don’t like systemd, you need to find another excuse.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1370002081.7985.95.camel@pi0307572

Re: systemd .service file conversion

2013-05-31 Thread Uoti Urpala

Helmut Grohne wrote:
 On Fri, May 31, 2013 at 01:44:12AM +0300, Uoti Urpala wrote:
  Steve Langasek wrote:
   I can't speak to other distributions, but in Debian, the systemd 
   maintainers
   are in no position to decide that Debian will agree to rewrite its
  
  Focusing on position to decide seems less than constructive.
 
 I believe that you are mistaking Steve's point here. His statement
 appears merely factual to me. And that is what it is. Some of the paths
 you were talking about are explained in the Debian policy as exceptions
 to FHS, and clearly it is not individual maintainers to decide how to
 change the policy.

Individual maintainers are generally not in position to support systemd
in Debian if everyone else opposes, but you're in no position to
introduce systemd to Debian would still be less than constructive. I
don't know what you mean by that FHS bit - I don't think anything
under /etc/default is listed as exception to FHS? 

  It makes a lot of sense to standardize those files across distributions.
  You don't seem to disagree with Debian following the FHS for example (or
  was your attitude to that our current paths work quite well already,
  thankyouverymuch too?). Why would custom /etc file locations be the
  very purpose of Debian's existence in a way that prohibits
  standardization, if other filesystem layout isn't?
 
 Again you appear to have a difficult time getting the argument. The
 purpose outlined was the integration work, not specific paths. Specific
 paths are merely a tool to get there. They can change, but that requires
 a lot of work and usually breaks tons of stuff. Indeed Debian is
 adopting a number of things from different distributions. That is a hard
 thing to do though, even for things that are already defacto standards.
 For example adopting the required filename encoding from Fedora turned
 out to be harder than expected (#701081). So given the work required to
 change such an aspect, the ones who want the change need pretty good
 arguments.

Nothing in Steve Langasek's message mentioned the amount of work. What
he said was This integration, which is *the very purpose* of Debian's
existence, is not for systemd upstream (or any upstream) to dictate.
Claiming that he was actually making an argument about how difficult the
change would be to implement seems rather far-fetched. Obviously _you_
want to comment on the implementation aspect, but that's not what I was
replying to earlier, and not something I failed to get.

The argument for changing is pretty obvious: standardization. I think
you're exaggerating the difficulty of changing for most of those files.
I think discussing the difficulty in more detail would not be meaningful
without considering particular cases. Anyway, my position is that
switching to cross-distro locations used by systemd is desirable; I'm
not saying it would have to be done for every file no matter what the
cost if something is particularly hard in practice. Whereas Langasek was
objecting more generally - he was clearly against such changes even if
easily doable.


  If you think there is something actually wrong with the default choices
  currently used by systemd, a much more constructive approach would be to
  get that fixed across distros, rather than have Debian use a different
  custom layout. Note that standardizing on the current Debian locations
  across distros would not have been a good choice for the above two
  files, as they include the rather arbitrary /default/ path.
 
 More often than not, there is no wrong with specific naming in
 standards. It just happens that you have to pick one. Indeed systemd
 appears to have come a bit late to the party and Debian has had a
 standard long before. Arguably systemd could be the one opting to adopt
 an existing standard.

I already addressed exactly this point in the text you're replying to:
Note that standardizing on the current Debian locations across distros
would not have been a good choice for the above two files,  There
was good reason to use paths different from the traditional Debian ones
for those two files. Systemd did adopt the Debian location for other
files.

  (Now this is of course false, because RedHat had
 their own file name policy well before the invention of systemd.)

I'm not sure what you were trying to say here (it's unclear what of your
previous text the false refers to). Anyway the systemd goal of more
standard paths meant discarding lots of Red Hat-specific paths too, like
things under /etc/sysinit/ (approximately equivalent to Debian
/etc/default/).

  This
 is more true for the socket activation API that systemd could have
 reasonably adopted from upstart, but chose not to do.

Didn't systemd actually have a socket activation API before upstart? I
don't remember exactly, but IIRC upstart at least got it rather late and
there was no standard long before systemd.


  If you oppose them just because they come from systemd upstream, well...
 
 It appears

Re: systemd .service file conversion

2013-05-31 Thread Jeff Epler

On Fri, May 31, 2013 at 02:08:01PM +0200, Josselin Mouette wrote:
 I disagree with this claim. The wheezy release for kfreebsd is a joke,
 and we should end it with jessie unless there are real users.

What makes me other than a real user?  Perhaps some users of Debian
are more equal^Wreal than others.

Jeff


signature.asc
Description: Digital signature

Re: systemd .service file conversion

2013-05-31 Thread Jeff Epler

On Thu, May 30, 2013 at 09:05:50PM +0200, Olav Vitters wrote:
 Do you actually run a kernel other than Linux and is anything other than
 Linux usable? I can understand it is not nice, but feels like the other
 options are bitrotting anyway.

Yes and yes.  Wheezy kfreebsd amd64 is dandy for server and OK for some
minor graphical desktop stuff (opengl is not in a good state right now,
at least with nvidia hardware: nouveau is no-go due to not having kernel
support and proprietary won't install).  if you want zfs on debian
(which is what I wanted) it's probably a better choice today than debian
linux with zfs-on-linux. (at least, that's the call I made)

There are some odd missing packages and problems, which I've filed a
number of patches for (e.g., three I've done this year are to build
valgrind; to improve gdb threads support; and to build mongodb) others
have recently filled in another missing piece with jdk7 support and I
generally get the sense that there is a core of smart people who are
dedicated to kfreebsd.

The idea that somehow users of non-linux kernels don't matter or don't
even exist as debian users is one of the most frustrating bits of this
whole thread.

Jeff


signature.asc
Description: Digital signature

Re: systemd .service file conversion

2013-05-31 Thread Игорь Пашев

2013/5/31 Jeff Epler jep...@unpythonic.net:
 Yes and yes.  Wheezy kfreebsd amd64 is dandy for server and OK for some
 minor graphical desktop stuff (opengl is not in a good state right now,
 at least with nvidia hardware: nouveau is no-go due to not having kernel
 support and proprietary won't install).  if you want zfs on debian
 (which is what I wanted) it's probably a better choice today than debian
 linux with zfs-on-linux. (at least, that's the call I made)


Debian GNU/kopensolaris is coming too ;-)

As for init system, my point is having different init systems for
different kernels is ok.
Having different init systems for the same kernel is pain in ass.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CALL-Q8wYp-8g_10snjquRMjqhw=9+5s2o6ixh6b7eb1_kn5...@mail.gmail.com

Re: systemd .service file conversion

2013-05-31 Thread Marco d'Itri

On May 31, Jeff Epler jep...@unpythonic.net wrote:

 The idea that somehow users of non-linux kernels don't matter or don't
 even exist as debian users is one of the most frustrating bits of this
 whole thread.
I'm sorry for the three kfreebsd users, but sometimes reality sucks.
Pretending that their needs are as much important as the needs of the 
99% of Debian users who use Linux does not make it true.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: systemd .service file conversion

2013-05-31 Thread Olav Vitters

On Fri, May 31, 2013 at 08:53:07AM -0500, Jeff Epler wrote:
 The idea that somehow users of non-linux kernels don't matter or don't
 even exist as debian users is one of the most frustrating bits of this
 whole thread.

I was just curious, not suggesting. I also asked this on an IRC channel
and heard that basic things like e.g. GNOME is not working. To me, if
you offer a version it should work fully and pass all QA test. I heard
that every package has to ensure that it compiles. Compiling for me is
just a basic thing. Shouldn't be just that, it should work fully and
pass all the QA tests, else it just is not at the same level as other
architectures as x86_64 and so on.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531150822.ga3...@bkor.dhs.org

Re: systemd .service file conversion

2013-05-31 Thread Thomas Goirand

On 05/28/2013 02:37 PM, Helmut Grohne wrote:
 On Mon, May 27, 2013 at 09:13:44AM +0200, Ond??ej Surý wrote:
 I would be quite happy to write service files for two (systemd, upstart) or
 three (systemd, upstart, openrc) of those in all my packages[*], if it
 stops the endless flamewar here. I would also be happy to have the
 requirement to support two (or three) of them in the Debian policy.
 
 My major point here was precisely that you are *not* done with just
 writing the service/job descriptions/scripts for all those init systems.
 You'd likely have to patch every single daemon to enable the socket
 activation method for those init systems, that the authors of your
 daemon did not like to use.
 
 If on the other hand you omit this patching, then that init system
 partially loses one of its selling points. So instead of supporting one
 init system properly, we support four init systems poorly.

Just to make sure I understood.

What selling point are you talking about? Why is it necessary to patch
daemons to have socket activation?

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51a8cc80.9050...@debian.org

Re: systemd .service file conversion

2013-05-31 Thread Ondřej Surý

On 31. 5. 2013, at 15:53, Jeff Epler jep...@unpythonic.net wrote:
 The idea that somehow users of non-linux kernels don't matter or don't
 even exist as debian users is one of the most frustrating bits of this
 whole thread.

I would happily support any non-linux kernel arch in form of integrating 
patches, but the reality is that Hurd and FreeBSD kernels are just toys.

That doesn't mean the toys are not important (...all work and no play...), they 
are, but they must not stop the inovation. And as we have sacrificed niche 
architecture and made them non-release, we must be also prepared to do the same 
with non-linux kernels if we have to.

Regards,
Ondrej

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/25726a79-ee8b-4bed-a5ad-c42ae925d...@sury.org

Re: systemd .service file conversion

2013-05-31 Thread Russ Allbery

Thomas Goirand z...@debian.org writes:
 On 05/28/2013 02:37 PM, Helmut Grohne wrote:

 My major point here was precisely that you are *not* done with just
 writing the service/job descriptions/scripts for all those init
 systems.  You'd likely have to patch every single daemon to enable the
 socket activation method for those init systems, that the authors of
 your daemon did not like to use.

 If on the other hand you omit this patching, then that init system
 partially loses one of its selling points. So instead of supporting one
 init system properly, we support four init systems poorly.

 Just to make sure I understood.

 What selling point are you talking about? Why is it necessary to patch
 daemons to have socket activation?

Socket activation is a neat solution to several long-standing problems
with socket-based daemons (either local or network):

1. It's difficult to tell when the daemon is fully initialized and ready
   to accept connections from the network, and therefore to determine
   ordering constraints during startup.  Daemons that fork and background
   themselves are *supposed* to not do that until they're set up to accept
   connections, but many do not follow this rule, and fixing them can be
   non-trivial.  Socket activation bypasses this whole problem by having
   the init system listen on the sockets so that connections are held in
   an accepted state until the daemon finishes spinning up, which mostly
   eliminates the need to worry about ordering and timing constraints
   between the daemons unless there's an actual deadlock.

2. Daemons that can use socket activation *exclusively* can offload a lot
   of complexity around such things as managing both IPv4 and IPv6 socket
   endpoints to well-tested code.

3. It's possible for daemons to crash and be restarted transparently to
   the end user in some situations because the socket can be passed to a
   newly-recovered daemon.  (There are significant limitations here, of
   course, but it does improve robustness for some services.)

4. One can hold off on spawning daemons until they're actually used, which
   can save system resources.

For more details, see:

http://0pointer.de/blog/projects/socket-activation.html

It's basically an abstraction and generalization of the inetd concept,
making it work with a much wider array of socket-based services.

Note that upstreams are going to start supporting this regardless of what
Debian does, to work better on Red Hat systems.  For example, I plan on
adding support for socket activation to the network services for which I'm
upstream.  There's really no reason not to, and the code required is
fairly simple.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bo7rhypb@windlord.stanford.edu

Re: systemd .service file conversion

2013-05-31 Thread Ben Hutchings

On Fri, May 31, 2013 at 06:12:38PM +0200, Ondřej Surý wrote:
 On 31. 5. 2013, at 15:53, Jeff Epler jep...@unpythonic.net wrote:
  The idea that somehow users of non-linux kernels don't matter or don't
  even exist as debian users is one of the most frustrating bits of this
  whole thread.
 
 I would happily support any non-linux kernel arch in form of integrating 
 patches, but the reality is that Hurd and FreeBSD kernels are just toys.
 
 That doesn't mean the toys are not important (...all work and no play...), 
 they are, but they must not stop the inovation.
[...]

Please don't talk about 'innovation' in Linux.  There really isn't
anything particularly new going on here, just incremental development
of useful features.  There is also plenty of work being done to add
new features to the FreeBSD kernel (not all of which gets merged back
into it) and apparently a fair amount on Hurd.  Their major weakness
at the moment is in hardware support (this is an extremely weak point
for Hurd), and that can mostly be dealt with by making them work
efficiently in VMs.

The real problem we have is that these three kernels are not matching
each other's features, and if we want to run mostly the same userland
on all of them then it can only rely on the common subset of features.
That potentially leaves Debian trailing behind Linux-only
distributions that aren't limited in this way.

I think it makes more sense for all the non-Linux kernels to be
supported through debian-ports, allowing porters to apply kernel-
specific workaround patches, drop unsupportable packages, and release
on their own schedule.  There is a risk, of course, that this results
in continuing divergence if patches don't get fed 'upstream' to the
main Debian archive.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531170441.gv4...@decadent.org.uk

Re: systemd .service file conversion

2013-05-31 Thread brian m. carlson

On Fri, May 31, 2013 at 06:12:38PM +0200, Ondřej Surý wrote:
 That doesn't mean the toys are not important (...all work and no
 play...), they are, but they must not stop the inovation. And as we
 have sacrificed niche architecture and made them non-release, we must
 be also prepared to do the same with non-linux kernels if we have to.

With regard to innovation, FreeBSD has had integration between traffic
control and the firewall in pf for a long time.  Linux still requires
that you assign arbitrary integers as markers and keep them in sync
between two different sets of configuration files, and I have never seen
a tool to handle this automatically.  pf also has had passive OS
fingerprinting far longer than Linux has, and it is well-documented and
works almost out of the box, unlike iptables on Linux.

I would argue that the FreeBSD (and originally, OpenBSD) kernels are far
more innovative (and far easier to use) in this respect.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: systemd .service file conversion

2013-05-31 Thread Zbigniew Jędrzejewski-Szmek

On Fri, May 31, 2013 at 04:45:49PM +0300, Uoti Urpala wrote:
   This
  is more true for the socket activation API that systemd could have
  reasonably adopted from upstart, but chose not to do.
 
 Didn't systemd actually have a socket activation API before upstart? I
 don't remember exactly, but IIRC upstart at least got it rather late and
 there was no standard long before systemd.
Looking at launchpad, it seems so:

Revision ID: james.h...@ubuntu.com-20110606170511-h7cm82b47vsv2y0o
Merge of lp:~jamesodhunt/upstart/upstream-udev+socket-bridges.

...while systemd had socket activation in current form since the beggining.

But chronology is less important then the technical differences between
the two interfaces.

In systemd a socket activated process gets the variable $LISTEN_FDS
and sockets as file descriptors 3, 4, ..., $LISTEN_FDS-1 [1].
The interface is very generic.

In upstart the process gets one socket, with the number given in
the variable $UPSTART_FDS [2]. The naming (a) doesn't make sense since
there's only one socket, (b) is tied to upstart, and (c) there's only
one socket.

The limitation to one socket is quite constraining, e.g. we like
apache to listen on both 80 and 443, and the requirement for apache to
open the second port itselfs makes it impossible to start apache
unpriviledged.

Zbyszek

[1] 
http://www.freedesktop.org/software/systemd/man/sd_listen_fds.html#Description
[2] http://manpages.ubuntu.com/manpages/precise/man7/socket-event.7.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531185352.gd28...@in.waw.pl

Re: systemd .service file conversion

2013-05-31 Thread Svante Signell

On Fri, 2013-05-31 at 08:59 -0500, Jeff Epler wrote:
 On Fri, May 31, 2013 at 02:08:01PM +0200, Josselin Mouette wrote:
  I disagree with this claim. The wheezy release for kfreebsd is a joke,
  and we should end it with jessie unless there are real users.
 
 What makes me other than a real user?  Perhaps some users of Debian
 are more equal^Wreal than others.

From 1984 by George Orwell: quoting freely: Everybody is equal but some
are more equal than others, a pig leader speech :)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1370027215.4618.14.camel@PackardBell-PC

Re: systemd .service file conversion

2013-05-31 Thread Svante Signell

Ah, sorry  wrong book: Animal farm, by the same author George Orwell: :)

1984 is about big brother watching you. (of course both very recommended
these days)

On Fri, 2013-05-31 at 21:06 +0200, Svante Signell wrote:
 On Fri, 2013-05-31 at 08:59 -0500, Jeff Epler wrote:
  On Fri, May 31, 2013 at 02:08:01PM +0200, Josselin Mouette wrote:
   I disagree with this claim. The wheezy release for kfreebsd is a joke,
   and we should end it with jessie unless there are real users.
  
  What makes me other than a real user?  Perhaps some users of Debian
  are more equal^Wreal than others.
 
 From 1984 by George Orwell: quoting freely: Everybody is equal but some
 are more equal than others, a pig leader speech :)
 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1370027566.4618.19.camel@PackardBell-PC

Re: systemd .service file conversion

2013-05-31 Thread Svante Signell

On Fri, 2013-05-31 at 16:33 +0200, Marco d'Itri wrote:
 On May 31, Jeff Epler jep...@unpythonic.net wrote:
 
  The idea that somehow users of non-linux kernels don't matter or don't
  even exist as debian users is one of the most frustrating bits of this
  whole thread.
 I'm sorry for the three kfreebsd users, but sometimes reality sucks.
 Pretending that their needs are as much important as the needs of the 
 99% of Debian users who use Linux does not make it true.

That's maybe the current situation, I'm one of them. Weren't I counted,
I found more than three? Give it a few years and make the same
statement again, do you dare :) Nothing is ever constant, things evolve
with time, Linux or no Linux.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1370028479.4618.26.camel@PackardBell-PC

Re: systemd .service file conversion

2013-05-31 Thread Roger Lynn

On 30/05/13 16:30, Matthias Klumpp wrote:
 2013/5/30 Marco d'Itri m...@linux.it:
 The /etc/ /lib/ /usr/lib/ split with files overriding each other,
 invented because RPM systems do not prompt the user on package upgrades
 and Red Hat does not support upgrading to the next major release.
 Well, that might have been one reason, but splitting the conf files
 has other advantages too. I like that I have the original file as
 reference, that I have very small config-override files which can
 easily be backed up, and it also simplifies updates, because I don't
 have to merge diffs of config files, but just need to adjust them
 later, if something has changed.

I prefer to be notified of changes to configuration files during upgrades so
that I know which configurations need updating, rather than just hoping that
the old config will work with the updated package and missing out on any new
options silently introduced in a master configuration file which I can't
even easily diff for updates.

Roger


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/evfn7a-03j@silverstone.rilynn.me.uk

Re: systemd .service file conversion

2013-05-31 Thread Helmut Grohne

Dear upstart developers,

debian-devel@l.d.o has been talking about socket activation interfaces.
The technical differences are nicely summarized:

On Fri, May 31, 2013 at 08:53:52PM +0200, Zbigniew J??drzejewski-Szmek wrote:
 But chronology is less important then the technical differences between
 the two interfaces.
 
 In systemd a socket activated process gets the variable $LISTEN_FDS
 and sockets as file descriptors 3, 4, ..., $LISTEN_FDS-1 [1].
 The interface is very generic.
 
 In upstart the process gets one socket, with the number given in
 the variable $UPSTART_FDS [2]. The naming (a) doesn't make sense since
 there's only one socket, (b) is tied to upstart, and (c) there's only
 one socket.
 
 The limitation to one socket is quite constraining, e.g. we like
 apache to listen on both 80 and 443, and the requirement for apache to
 open the second port itselfs makes it impossible to start apache
 unpriviledged.
 
 Zbyszek
 
 [1] 
 http://www.freedesktop.org/software/systemd/man/sd_listen_fds.html#Description
 [2] http://manpages.ubuntu.com/manpages/precise/man7/socket-event.7.html

Is there any chance for upstart to adopt the socket activation interface
from systemd? As has been pointed out above, the interface is more
generic. Having upstart and systemd differentiate on interfaces does not
serve any good. Instead upstart could benefit from daemons already
supporting systemd style socket activation. Having one interface to
socket activation would greatly reduce the amount of integration work to
be done by distributions such as Debian. I am aware that this is kind of
a bike shedding discussion. The value to be gained is the uniformity
though.

If this is not possible, please briefly lay out the reason (or point to
previous discussion of this matter).

Thanks in advance

Helmut


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130531213138.ga15...@alf.mars

Re: systemd .service file conversion

2013-05-31 Thread Lennart Poettering

On Fri, 31.05.13 23:31, Helmut Grohne (hel...@subdivi.de) wrote:

 debian-devel@l.d.o has been talking about socket activation interfaces.
 The technical differences are nicely summarized:
 
 On Fri, May 31, 2013 at 08:53:52PM +0200, Zbigniew J??drzejewski-Szmek wrote:
  But chronology is less important then the technical differences between
  the two interfaces.
  
  In systemd a socket activated process gets the variable $LISTEN_FDS
  and sockets as file descriptors 3, 4, ..., $LISTEN_FDS-1 [1].
  The interface is very generic.
  
  In upstart the process gets one socket, with the number given in
  the variable $UPSTART_FDS [2]. The naming (a) doesn't make sense since
  there's only one socket, (b) is tied to upstart, and (c) there's only
  one socket.
  
  The limitation to one socket is quite constraining, e.g. we like
  apache to listen on both 80 and 443, and the requirement for apache to
  open the second port itselfs makes it impossible to start apache
  unpriviledged.
  
  Zbyszek
  
  [1] 
  http://www.freedesktop.org/software/systemd/man/sd_listen_fds.html#Description
  [2] http://manpages.ubuntu.com/manpages/precise/man7/socket-event.7.html
 
 Is there any chance for upstart to adopt the socket activation interface
 from systemd? As has been pointed out above, the interface is more
 generic. Having upstart and systemd differentiate on interfaces does not
 serve any good. Instead upstart could benefit from daemons already
 supporting systemd style socket activation. Having one interface to
 socket activation would greatly reduce the amount of integration work to
 be done by distributions such as Debian. I am aware that this is kind of
 a bike shedding discussion. The value to be gained is the uniformity
 though.
 
 If this is not possible, please briefly lay out the reason (or point to
 previous discussion of this matter).

To provide a bit of context: we deliberately designed our socket passing
logic to be generic enough to be implementable elsewhere than systemd
(i.e. we kept it as minimalistic as possible and kept any reference to the
systemd name out of it). I remember even emailing the Upstart guys about
that, but I never got any reply. This was a long long time before Upstart
added socket activation.

Note that what Upstart eventually implemented regarding socket
activation kinda misses the major point of it. 

Socket activation in the launchd/systemd sense is a tool that (among
other things) allows you to get rid of ordering dependencies between clients
and servers, and systematically parallelize their startup. 

Here's an example: if you have a syslog daemon and a service that logs
to syslog, then the former is the server, the latter is the client. Now,
let's say you want to start both at boot. In classic init systems you
would have to make sure that you first start the syslog daemon, and only
after that finished initialization -- and hence established the syslog
socket in the file system -- you can go on and start the client. Hence
you need to express this dependency, and if you don't do that you will
lose messages. Now, if you employ socket activation for this, then you'd
first establish the syslog socket from your init system, and then start
the syslog daemon and its client *at the same time*. Since the socket is
known to be established before your two services initialize logging will
always just work -- and you do not have to express any dependency
explicitly anymore! On top of that, parallelization is maximized since
client and server start at the same time, and do not have to wait for
each other (at least until the socket buffer runs full and the client
starts to block, but that hopefully happens relatively late). Things
hence get simpler, and faster at the same time!

Now, if you understood the scheme above then you will have noticed that
socket activation is *not* about lazy activation here. You start both
services early on, and at the same time. You do not wait for an incoming
connection. And that's something Upstart cannot do with its scheme. In
Upstart, since the sockets are part of the socket connection event, you
always need the connection to take place first.

Hence: on systemd (and launchd where idea comes from) socket activation
is primarily about getting rid of dependencies and increased
parallelization. And secondarily about lazy activation. On Upstart
however socket activation is about lazy activtion and nothing else.

In my eyes this makes socket activation in Upstart pretty much 
uninteresting and misses the major point of it. (Well, at least to the
level I understood Upstart. Maybe I totally missed how it works, but
from the docs, it appears it cannot create the listening socket, and
then activate its service from any other event than the actual incoming
connection event of it, but still have the listening socket passed to
the service.)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a

Re: systemd .service file conversion

2013-05-30 Thread Riku Voipio

On Wed, May 29, 2013 at 09:10:41PM +0200, Wouter Verhelst wrote:
  This kind of madness is precisely described here:
  http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html
 [zillionth link to linux is not about choice mail]

Because it's a very good read, still years later. It is unfortunate
that the community hasn't learned from it.

 At Debian, traditionally we support more than one choice (at least for a
 while), until the community at large decides that option X is the best
 one (and then we drop support for all the other options). The downside
 of that is that it takes a lot longer for us to make a choice, but
 eventually you usually get the better option.

This is stockholm syndromish - because Debian is held behind times by
lack of decision making, we start finding good things in being behind.

By switching early we can affect how a piece of software will evolve.
Is there something you would like to change in systemd? Now it still
probably possible - 2 years from now it has shipped in RHEL, and books
will have been written about it - and changing it will be much harder.

So our inability choose early means that we cannot influence the
community as large - or even our own distribution in long term. While
we are busy maintaining multiple indirection layers to support user
choice, the early switching distributions are crafting the software
that will eventually become the choice.

Riku


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130530084651.ga17...@afflict.kos.to

Re: systemd .service file conversion

2013-05-30 Thread Salvo Tomaselli

 This is stockholm syndromish - because Debian is held behind times by
 lack of decision making, we start finding good things in being behind.

Do you realize that fedora is the beta version for red hat? They use the 
community to get free testing for their commercial product.
Personally as a debian user I prefer having a system that works rather than 
being used as a guinea pig for a commercial product.

I don't see how forcing users to use immature software that doesn't yet work 
very well is a good thing for anyone (except if you are a commercial company 
and use your free product to get free beta testing).

I have tried systemd, and I like the approach it has, and in a few years I 
believe it has potential. But... using it to restart my computer i need to do 
an hard reset (and think of how happy would I be if my computer had been a 
server in a rack on the other side of the planet), and gave me several 
problems related to switching from X11 to vt and vice versa.

At this point I can't see what decision is there to be made, systemd is not 
ready yet to replace sysvinit, if and when it will work reliably we can have 
this conversation.

On a side note about Poettering, sometimes pulseaudio gets pulled in by some 
package that I install, and when this happens I stop hearing sounds from my 
computer, then I know I just need to remove it and everything will be fine 
again (this happened 2 months ago the last time), I am sure there is a fix for 
this but personally I find it much easier to just remove some piece of 
software that I didn't even need in the 1st place and is just causing 
malfunctioning after years of causing malfunctioning. So I really don't regard 
him as the best person there is to write core parts of my system. I'd trust 
him maybe with things like cowsay or nyancat that wouldn't cause too much 
havoc when they should fail.

-- 
Salvo Tomaselli

http://web.student.chalmers.se/~saltom/

signature.asc
Description: This is a digitally signed message part.

Re: systemd .service file conversion

2013-05-30 Thread Sune Vuorela

On 2013-05-30, Riku Voipio riku.voi...@iki.fi wrote:
 By switching early we can affect how a piece of software will evolve.
 Is there something you would like to change in systemd? Now it still
 probably possible - 2 years from now it has shipped in RHEL, and books
 will have been written about it - and changing it will be much harder.

 So our inability choose early means that we cannot influence the
 community as large - or even our own distribution in long term. While
 we are busy maintaining multiple indirection layers to support user
 choice, the early switching distributions are crafting the software
 that will eventually become the choice.

Wise words.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnkqe9ja.j8.nos...@sshway.ssh.pusling.com

Re: systemd .service file conversion

On Wed, 29 May 2013 21:10:41 +0200, Wouter Verhelst
wou...@debian.org wrote:
At Debian, traditionally we support more than one choice (at least for a
while), until the community at large decides that option X is the best
one (and then we drop support for all the other options). The downside
of that is that it takes a lot longer for us to make a choice, but
eventually you usually get the better option.

The only reason why we seem to be unable to do so this time is that some
people claim the sky will fall if we don't make a choice NOW!!1!

I think it makes perfect sense for us to support systemd, openrc, and
upstart, at least for the time being; I doubt we'll continue supporting
all three options until the end of times, but we don't have to do that.
At any rate, we *need* to support multiple options for our non-Linux
ports, too, so this wouldn't be a lost effort.

The init system case is special because supporting another init script
system will most probably mean that all packages delivering an init
script ($ ls /etc/init.d/ | wc -l = 116 on my small notebook system)
will have to adapt. This is a major transition, and while we offer
multiple init systems as officially supported, additional work is
needed by all developers.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom  | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1uhzzb-0008j5...@swivel.zugschlus.de

Re: systemd .service file conversion

On Thu, 30 May 2013 11:46:51 +0300, Riku Voipio riku.voi...@iki.fi
wrote:
By switching early we can affect how a piece of software will evolve.

This is the case with software that has a cooperative upstream.
systemd's upstream is known not to be.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom  | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ui00a-0008jd...@swivel.zugschlus.de

Re: systemd .service file conversion

2013-05-30 Thread Sam Morris

On Thu, 30 May 2013 11:38:22 +0200, Salvo Tomaselli wrote:
 I have tried systemd, and I like the approach it has, and in a few years
 I believe it has potential. But... using it to restart my computer i
 need to do an hard reset (and think of how happy would I be if my
 computer had been a server in a rack on the other side of the planet),
 and gave me several problems related to switching from X11 to vt and
 vice versa.

If you haven't already, please file bugs for these issues so that they 
can be investigated and fixed.

-- 
Sam Morris
https://robots.org.uk/
 
PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/pan.2013.05.30.10.33...@robots.org.uk

Re: systemd .service file conversion

2013-05-30 Thread Gergely Nagy

Marc Haber mh+debian-de...@zugschlus.de writes:

 On Thu, 30 May 2013 11:46:51 +0300, Riku Voipio riku.voi...@iki.fi
 wrote:
By switching early we can affect how a piece of software will evolve.

 This is the case with software that has a cooperative upstream.
 systemd's upstream is known not to be.

I never quite understood why people seem to think systemd upstream is
uncooperative (well, apart from the whole non-linux porting deal, where
their stance is completely understandable too). My experience so far
suggests otherwise: I've have had very fruitful interactions with them,
multiple times, in person and over the wire aswell.

From the mailing list and IRC channel, I get the same impression I got
when personally involved.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwrc7kuf.fsf@algernon.balabit

Re: systemd .service file conversion

On Thu, May 30, 2013 at 12:22:34PM +0200, Marc Haber wrote:
 This is the case with software that has a cooperative upstream.
 systemd's upstream is known not to be.

I've seen as well as attended various conferences where systemd was
explained. There have also been various systemd specific events. There
was also a open meeting between systemd developers and systemd users
at FOSDEM (which I attended). Interested people from various
distributions discussed the state of systemd, what they want, etc.
Upstream discussed planned changes, etc.

Above is what happens in practice. Seems cooperative.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130530121102.gd16...@bkor.dhs.org

Re: systemd .service file conversion

On Thu, May 30, 2013 at 12:21:33PM +0200, Marc Haber wrote:
 The init system case is special because supporting another init script
 system will most probably mean that all packages delivering an init
 script ($ ls /etc/init.d/ | wc -l = 116 on my small notebook system)
 will have to adapt. This is a major transition, and while we offer
 multiple init systems as officially supported, additional work is
 needed by all developers.

The systemd files should be pushed upstream (this is what other
distributions have done and will do). Furthermore, systemd support
sysvinit. Obviously there will be a pain when switching, but then I
guess your argument is that any change is bad?

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130530121653.ge16...@bkor.dhs.org

Re: systemd .service file conversion

2013-05-30 Thread Marco d'Itri

On May 30, Gergely Nagy alger...@balabit.hu wrote:

 I never quite understood why people seem to think systemd upstream is
 uncooperative (well, apart from the whole non-linux porting deal, where
 their stance is completely understandable too). My experience so far
There is also the kill features Red Hat does not care about deal, 
and the invent a new a configuration files scheme because it better 
suits RPM and Red Hat policies deal.
Upstream is very cooperative, as long as your needs align with the ones 
of Red Hat.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: systemd .service file conversion

2013-05-30 Thread Mathieu Parent

(I'm afraid to feed the troll)

2013/5/30 Marco d'Itri m...@linux.it:
 On May 30, Gergely Nagy alger...@balabit.hu wrote:

 I never quite understood why people seem to think systemd upstream is
 uncooperative (well, apart from the whole non-linux porting deal, where
 their stance is completely understandable too). My experience so far
 There is also the kill features Red Hat does not care about deal,

Do you have an example?

 and the invent a new a configuration files scheme because it better
 suits RPM and Red Hat policies deal.

Do you have an example?

I have a example that show systemd taking non-RH solutions: /etc/hostname [ref]

[ref]: http://0pointer.de/blog/projects/the-new-configuration-files

 Upstream is very cooperative, as long as your needs align with the ones
 of Red Hat.

examples?

Regards
--
Mathieu Parent


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAFX5sby+c5JAabcZoaByv_=jR5FtYv=0f+lqdrxb4fiwhgx...@mail.gmail.com

Re: systemd .service file conversion

Salvo Tomaselli wrote:
 I have tried systemd, and I like the approach it has, and in a few years I 
 believe it has potential. But... using it to restart my computer i need to do 
 an hard reset (and think of how happy would I be if my computer had been a 
 server in a rack on the other side of the planet), and gave me several 
 problems related to switching from X11 to vt and vice versa.

Do you have any reason at all to believe that these were problems with
systemd, rather than problems in Debian configuration or mostly
independent bugs in other software that happened to trigger under
systemd? Most likely the init that works most reliably in Debian for
basic tasks like booting up a common default system and rebooting is
still sysvinit. But that's not because of any positive quality of
sysvinit, but rather because a lot of effort has been spent to paper
over any problems.

ANY init system can be tweaked to be able boot up and reboot a simple
default system. That's not a relevant criterion to choose between them.
If boot fails completely, in most cases that just demonstrates a lack of
final polish. To make meaningful comparisons between systems, you need
to at least see whether there are more fundamental problems underlying
the failures, or why fixing or working around them takes more effort
with some system.


 On a side note about Poettering, sometimes pulseaudio gets pulled in by some 
 package that I install, and when this happens I stop hearing sounds from my 
 computer, then I know I just need to remove it and everything will be fine

I don't think PulseAudio works as an argument against him. See this mail
for more details:
https://lists.debian.org/1354241767.1887.76.camel@glyph.nonexistent.invalid



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1369921815.3628.71.camel@glyph.nonexistent.invalid

Re: systemd .service file conversion

Mathieu Parent wrote:
 2013/5/30 Marco d'Itri m...@linux.it:
  and the invent a new a configuration files scheme because it better
  suits RPM and Red Hat policies deal.
 
 Do you have an example?

I think he's referring to the etc-overrides-lib semantics that systemd
uses for configuration files. But it's wrong to describe that as better
suits RPM and Red Hat policies; it's simply a better system than always
having all configuration files in /etc and expecting users to possibly
modify those same files, for reasons that are not specific to Red Hat.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1369922163.3628.75.camel@glyph.nonexistent.invalid

Re: systemd .service file conversion

2013-05-30 Thread Jonathan Dowland

On Thu, May 30, 2013 at 04:50:15PM +0300, Uoti Urpala wrote:
 Do you have any reason at all to believe that these were problems with
 systemd, rather than problems in Debian configuration or mostly
 independent bugs in other software that happened to trigger under
 systemd?

Whether or not systemd is responsible is not important if we are considering
systemd as a default init: even if it is not responsible, if it exposes
important bugs, those bugs need to be addressed before we could make a switch.
What we need to make sure works is systemd in Debian, that is, integration
is where all the work is going to be.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130530141451.GA2864@debian

Re: systemd .service file conversion

2013-05-30 Thread Marco d'Itri

On May 30, Mathieu Parent math.par...@gmail.com wrote:

 (I'm afraid to feed the troll)
Hint: before accusing somebody of trolling it is a good idea to find out 
who he is.

  There is also the kill features Red Hat does not care about deal,
 Do you have an example?
Persistent naming of network interfaces.

  and the invent a new a configuration files scheme because it better
  suits RPM and Red Hat policies deal.
 Do you have an example?
The /etc/ /lib/ /usr/lib/ split with files overriding each other, 
invented because RPM systems do not prompt the user on package upgrades 
and Red Hat does not support upgrading to the next major release.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: systemd .service file conversion

2013-05-30 Thread Mathieu Parent

2013/5/30 Marco d'Itri m...@linux.it:
 On May 30, Mathieu Parent math.par...@gmail.com wrote:

 (I'm afraid to feed the troll)
 Hint: before accusing somebody of trolling it is a good idea to find out
 who he is.
I apologize.



--
Mathieu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAFX5sbw4=z9+sr-fz4jpmmrhjbsywreqcf+ce6dijjcjxpw...@mail.gmail.com

Re: systemd .service file conversion

2013-05-30 Thread Matthias Klumpp

2013/5/30 Marco d'Itri m...@linux.it:
On May 30, Mathieu Parent math.par...@gmail.com wrote:
[···]
There is also the kill features Red Hat does not care about deal,
Do you have an example?
Persistent naming of network interfaces.
... is entirely optional, and can be disabled if someone doesn't want
it - but I can't see what is bad about it...
Also, rationale and introduction to this feature is nicely documented:

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
Or do you mean something else?

and the invent a new a configuration files scheme because it better
suits RPM and Red Hat policies deal.
Do you have an example?
The /etc/ /lib/ /usr/lib/ split with files overriding each other,
invented because RPM systems do not prompt the user on package upgrades
and Red Hat does not support upgrading to the next major release.
Well, that might have been one reason, but splitting the conf files
has other advantages too. I like that I have the original file as
reference, that I have very small config-override files which can
easily be backed up, and it also simplifies updates, because I don't
have to merge diffs of config files, but just need to adjust them
later, if something has changed.
So, this is not really RHEL specific, and some other non-RH software
also has this scheme of storing config files.
Regards,
Matthias

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAKNHny9ai+tL7mRb5qxyZ5vTWHuW54kRAEXE5f=x9y8tft6...@mail.gmail.com

Re: systemd .service file conversion

Jonathan Dowland wrote:
 On Thu, May 30, 2013 at 04:50:15PM +0300, Uoti Urpala wrote:
  Do you have any reason at all to believe that these were problems with
  systemd, rather than problems in Debian configuration or mostly
  independent bugs in other software that happened to trigger under
  systemd?
 
 Whether or not systemd is responsible is not important if we are considering
 systemd as a default init: even if it is not responsible, if it exposes

You have the context wrong here. considering systemd as a default init
is too vague.

 important bugs, those bugs need to be addressed before we could make a switch.
 What we need to make sure works is systemd in Debian, that is, integration
 is where all the work is going to be.

Yes, there is integration work left. But that's really about the
question is Debian ready to switch all user machines to systemd right
now using the current packages?, and I think nobody would answer yes
to that (before also updating systemd to a much newer upstream version,
etc). I'm pretty sure that was not the context of the mail I was
replying to. He was confusing what were likely integration issues with
what would be more fundamental issues with systemd itself (that would
make it less desirable to do the integration work and switch at all),
and I tried to explain the difference.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1369927900.3628.93.camel@glyph.nonexistent.invalid

Re: systemd .service file conversion

On Thu, 30 May 2013 17:07:08 +0200, Matthias Klumpp m...@debian.org
wrote:
So, this is not really RHEL specific, and some other non-RH software
also has this scheme of storing config files.

And it is still completely inferior even to dpkg-conffile handling,
which has huge wishes left open as well.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom  | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ui5f6-0004wa...@swivel.zugschlus.de

Re: systemd .service file conversion

On Thu, 30 May 2013 14:16:53 +0200, Olav Vitters o...@vitters.nl
wrote:
On Thu, May 30, 2013 at 12:21:33PM +0200, Marc Haber wrote:
 The init system case is special because supporting another init script
 system will most probably mean that all packages delivering an init
 script ($ ls /etc/init.d/ | wc -l = 116 on my small notebook system)
 will have to adapt. This is a major transition, and while we offer
 multiple init systems as officially supported, additional work is
 needed by all developers.

The systemd files should be pushed upstream (this is what other
distributions have done and will do). Furthermore, systemd support
sysvinit.

How many features of systemd do we lose if we only use it to invoke
daemons via the init script compatibility layer? I doubt the change
makes sense if we end up doing things this way.

Obviously there will be a pain when switching, but then I
guess your argument is that any change is bad?

My argument is that the one job one tool approach that Unixoid OSses
use is a good approach and that I am extremely reluctant to drop it 
for a topic _this_ central in the operating system.

And I am also opposing changes that will help in dropping the
universal out of Debian's claim.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom  | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ui5h3-0004wk...@swivel.zugschlus.de

Re: systemd .service file conversion

On Thu, May 30, 2013 at 04:35:07PM +0200, Marco d'Itri wrote:
 On May 30, Mathieu Parent math.par...@gmail.com wrote:
  Do you have an example?
 The /etc/ /lib/ /usr/lib/ split with files overriding each other, 
 invented because RPM systems do not prompt the user on package upgrades 
 and Red Hat does not support upgrading to the next major release.

I assume this is your interpretation? Upstream never said anything like
above. I forgot the details, just has nothing to do with what you're
suggesting.

In any case, as a sysadmin you can configure systemd in /etc. This is
pretty much like any other package. Aside from that there are some files
somewhere else.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130530162721.gf16...@bkor.dhs.org

Re: systemd .service file conversion

Matthias Klumpp wrote:
 013/5/30 Marco d'Itri m...@linux.it:
  On May 30, Mathieu Parent math.par...@gmail.com wrote:
 [···]
   There is also the kill features Red Hat does not care about deal,
  Do you have an example?
  Persistent naming of network interfaces.
 ... is entirely optional, and can be disabled if someone doesn't want
 it - but I can't see what is bad about it...
 Also, rationale and introduction to this feature is nicely documented:
  
 http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
 Or do you mean something else?

I think Marco meant udev dropping support for the older variant of
persistent names, the one the article you linked to refers at 'For a
longer time udev shipped support for assigning permanent ethX names to
certain interfaces based on their MAC addresses.'.

As described in the article, there certainly were reasons other than
Red Hat does not care about it to drop this feature. Whether it would
have been preferable to keep optional support somewhat longer for
backwards compatibility is another question.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1369931671.3628.106.camel@glyph.nonexistent.invalid

Re: systemd .service file conversion

Marc Haber wrote:
 On Thu, 30 May 2013 17:07:08 +0200, Matthias Klumpp m...@debian.org
 wrote:
 So, this is not really RHEL specific, and some other non-RH software
 also has this scheme of storing config files.
 
 And it is still completely inferior even to dpkg-conffile handling,
 which has huge wishes left open as well.

False. The message you replied to already listed advantages over
dpkg-conffile handling. This was also already discussed before:
https://lists.debian.org/1336580040.28230.9.camel@glyph.nonexistent.invalid



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1369935171.3628.110.camel@glyph.nonexistent.invalid

Re: systemd .service file conversion

2013-05-30 Thread Thomas Goirand

On 05/30/2013 03:10 AM, Wouter Verhelst wrote:
 I think it makes perfect sense for us to support systemd, openrc, and
 upstart, at least for the time being; I doubt we'll continue supporting
 all three options until the end of times, but we don't have to do that.

I very much like the idea to give a chance to all solutions before we
decide which one we should keep. At least, I would like to have enough
time to work with the GSoC student on OpenRC this summer, to see how it
turns out.

On 05/30/2013 04:46 PM, Riku Voipio wrote:
 By switching early we can affect how a piece of software will evolve.
 Is there something you would like to change in systemd? Now it still
 probably possible - 2 years from now it has shipped in RHEL, and books
 will have been written about it - and changing it will be much harder.

Nobody prevents you to use and test it *now*. Systemd is in Debian, and
many package provide support for it. If you were to send me some patches
to support it (or upstart...), I'd happily apply the patch, and I'm sure
that many other DDs would do the same.

Though, I'm really not sure that if Debian decides to adopt Systemd now,
rather than a bit later, it will influence its development, or change
anything at all upstream.

On 05/30/2013 04:46 PM, Riku Voipio wrote:
 While we are busy maintaining multiple indirection layers to
 support user choice

I don't think this is what Wouter was talking about (eg, he never said
we should leave this as a choice to the user). He's basically saying
that *we* need time to test things, and see how they are, and make a
choice later, with enough information in hands. I agree with that view
(Wouter, tell me if I read your message wrongly, I all but want to put
words in your mouth that you never said).

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51a791fd.6090...@debian.org

Re: systemd .service file conversion

2013-05-30 Thread Russ Allbery

Uoti Urpala uoti.urp...@pp1.inet.fi writes:
 Marc Haber wrote:

 And it is still completely inferior even to dpkg-conffile handling,
 which has huge wishes left open as well.

 False. The message you replied to already listed advantages over
 dpkg-conffile handling. This was also already discussed before:
 https://lists.debian.org/1336580040.28230.9.camel@glyph.nonexistent.invalid

We've had this discussion a lot.  There is an ongoing technical
disagreement of opinion about the tradeoffs.  Pointing out that you've
previously posted your side of the argument isn't any more likely to
change anyone's mind than it did when you posted it the first time.  The
people who disagreed with your arguments the first time are still going to
disagree with them now, and are going to be no more convinced than they
were the first time.

In fact, given the tone that you use in these discussions and the nature
of human psychology, it's quite likely that the more you post on this
topic, the *less* people are going to agree with you.

If you want to see systemd adopted by default in Debian, the best thing
that you could do to achieve that goal, given your communication style, is
to stop sending mail about it to debian-devel.  Every time you post
another one of these sorts of messages, you further harden opposition to
systemd.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4goz6a3@windlord.stanford.edu

Re: systemd .service file conversion

2013-05-30 Thread Wouter Verhelst

On 30-05-13 19:53, Thomas Goirand wrote:
 On 05/30/2013 04:46 PM, Riku Voipio wrote:
 While we are busy maintaining multiple indirection layers to
 support user choice
 
 I don't think this is what Wouter was talking about (eg, he never said
 we should leave this as a choice to the user). He's basically saying
 that *we* need time to test things, and see how they are, and make a
 choice later, with enough information in hands.

correct, that's what I meant.

We may end up with multiple indirection layers to support user choice,
but that shouldn't be the goal; the goal should be to test the options
in unstable, and figure out, as a project, what the best option is given
our requirements.

I don't expect many users to use anything except the default init system
in Debian. Anyone who thinks we need to support that level of choice
either has an agenda, or is delusional.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51a79dd4.4000...@debian.org

Re: systemd .service file conversion

On Thu, May 30, 2013 at 06:27:13PM +0200, Marc Haber wrote:
 On Thu, 30 May 2013 14:16:53 +0200, Olav Vitters o...@vitters.nl
 wrote:
 On Thu, May 30, 2013 at 12:21:33PM +0200, Marc Haber wrote:
  The init system case is special because supporting another init script
  system will most probably mean that all packages delivering an init
  script ($ ls /etc/init.d/ | wc -l = 116 on my small notebook system)
  will have to adapt. This is a major transition, and while we offer
  multiple init systems as officially supported, additional work is
  needed by all developers.
 
 The systemd files should be pushed upstream (this is what other
 distributions have done and will do). Furthermore, systemd support
 sysvinit.
 
 How many features of systemd do we lose if we only use it to invoke
 daemons via the init script compatibility layer? I doubt the change
 makes sense if we end up doing things this way.

If there is a systemd conf file, it overrides the sysvinit script.

Systemd handles sysvinit scripts, so the transition can be gradual. I've
mentioned that any systemd conf file should be upstreamed and is being
upstreamed. So by just packaging newer versions Debian should get these
files without doing much.

Note that supporting multiple init scripts at the same time can trigger
a whole bunch of bugs. E.g. some software can see systemd while it is
compiled, enable that support and then it might not work if systemd is
not the init system.

 Obviously there will be a pain when switching, but then I
 guess your argument is that any change is bad?
 
 My argument is that the one job one tool approach that Unixoid OSses
 use is a good approach and that I am extremely reluctant to drop it 
 for a topic _this_ central in the operating system.

It has multiple tools and various APIs for those tools.

E.g. Canonical wrote a few own tools using the same dbus API. Then they
use logind (or whatever the name is) on Upstart. It is another
freedesktop.org project. Best to influence things is to get involved
when asked, not after the fact.

The goal is to make the boot more standard across distributions. So no
unneeded differences in some configuration files, systemd conf files
which are generic enough to be included upstream, etc.

In the current state, each distribution seems to have their own sysvinit
file in packages. All unneeded. Then there are some differences where
some boot configuration options are stored. If you strive to keep those
differences, then systemd is not for you. There will be some pain by
changing existing distribution-specific tools to look for the new
location. The existing distributions are ok with that (I talked to
various systemd packagers from various distributions @ FOSDEM).

 And I am also opposing changes that will help in dropping the
 universal out of Debian's claim.

Do you actually run a kernel other than Linux and is anything other than
Linux usable? I can understand it is not nice, but feels like the other
options are bitrotting anyway.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130530190550.ga25...@bkor.dhs.org

Re: systemd .service file conversion

On Thu, 30 May 2013 21:05:50 +0200, Olav Vitters o...@vitters.nl
wrote:
On Thu, May 30, 2013 at 06:27:13PM +0200, Marc Haber wrote:
 And I am also opposing changes that will help in dropping the
 universal out of Debian's claim.

Do you actually run a kernel other than Linux

Actually no, but it is a pleasure to see Debian move towards this
freedom with every new release. systemd would put this freedom farther
away than it ever was.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom  | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ui9py-0005xc...@swivel.zugschlus.de

Re: systemd .service file conversion

On Fri, 31 May 2013 01:53:01 +0800, Thomas Goirand z...@debian.org
wrote:
Though, I'm really not sure that if Debian decides to adopt Systemd now,
rather than a bit later, it will influence its development, or change
anything at all upstream.

Of course it won't. Upstream and Red Hat have shown many times that
they just don't care.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom  | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ui9qj-0005xp...@swivel.zugschlus.de

Re: systemd .service file conversion

Russ Allbery wrote:
 Uoti Urpala uoti.urp...@pp1.inet.fi writes:
  Marc Haber wrote:
  And it is still completely inferior even to dpkg-conffile handling,
  which has huge wishes left open as well.
 
  False. The message you replied to already listed advantages over
  dpkg-conffile handling. This was also already discussed before:
  https://lists.debian.org/1336580040.28230.9.camel@glyph.nonexistent.invalid
 
 We've had this discussion a lot.  There is an ongoing technical
 disagreement of opinion about the tradeoffs.

While there is room for reasonable disagreement about the relative
benefits of different configuration setups, completely inferior even to
dpkg-conffile handling is not part of any reasonable disagreement. That
claim is simply false.

   Pointing out that you've
 previously posted your side of the argument isn't any more likely to
 change anyone's mind than it did when you posted it the first time.  The
 people who disagreed with your arguments the first time are still going to

I did not post the link to point out I've previously posted my side,
but to avoid repeating the same discussion again. To show what the
benefits are without posting the same thing a second time, and to
generally show that there already was a discussion about this topic
before. I doubt everyone remembers a discussion from a year ago even if
they did read it at the time, and it's not obvious to what degree Marc
Haber himself was aware of it; at least he did not participate in that
discussion.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1369946197.3628.131.camel@glyph.nonexistent.invalid

Re: systemd .service file conversion

2013-05-30 Thread Steve Langasek

On Thu, May 30, 2013 at 09:05:50PM +0200, Olav Vitters wrote:
 The goal is to make the boot more standard across distributions. So no
 unneeded differences in some configuration files, systemd conf files
 which are generic enough to be included upstream, etc.

 In the current state, each distribution seems to have their own sysvinit
 file in packages. All unneeded. Then there are some differences where
 some boot configuration options are stored. If you strive to keep those
 differences, then systemd is not for you. There will be some pain by
 changing existing distribution-specific tools to look for the new
 location. The existing distributions are ok with that (I talked to
 various systemd packagers from various distributions @ FOSDEM).

I'm assuming you're talking here about things like /etc/default/locale and
/etc/default/keyboard, which systemd upstream fails to handle.

I can't speak to other distributions, but in Debian, the systemd maintainers
are in no position to decide that Debian will agree to rewrite its
system-level integration code (which works quite well already,
thankyouverymuch) to conform to an arbitrary rule from systemd upstream.
This integration, which is *the very purpose* of Debian's existence, is not
for systemd upstream (or any upstream) to dictate.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd .service file conversion