Bug#727708: On diversity

[Russ Allbery]

Uoti Urpala  writes:

> I consider the effect on the init system decision process so far to
> already be an example of actual negative effects.

Fair enough.  You're certainly entitled to your opinion.  I don't agree
with you, and I think it's unlikely either of us are going to change each
other's mind, on this or on the other points you mention.

I would really appreciate it if you would stop reiterating your position
on non-Linux ports in this bug, though.  I think everyone who has read
either this mailing list or debian-devel is, at this point, well aware of
your position, and has heard all of your arguments.  Restating them just
provokes more argument, none of which has any possibility of changing
anyone's mind, and hence is simply noise from the perspective of this
discussion.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#727708: On diversity

[Uoti Urpala]

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

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

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

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

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

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

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

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


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

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

[Michael Biebl]

Am 19.01.2014 11:59, schrieb Bastian Blank:
> On Sat, Jan 18, 2014 at 11:33:32PM +0100, Michael Biebl wrote:
>> On Sat, Jan 18, 2014 at 01:20:41PM +0100, Bastian Blank wrote:
>>> - lvm2.service is statically hooked to local-fs.target, as all local
>>>   mounts.
>> lvm2.service is not a local mount, so that is not really a justification for
>> enabling the service statically.
> 
> Please show me a better target.  This is what the generator does, so I
> assume there exists none.

This is a misunderstanding. The target is fine. I was just saying that
using the target as justification for enabling the service statically is
flawed.
That said, I don't really care if you hook up the service statically.
I'm just a bit surprised since you objected the generator as you wanted
the possibility to disable the service.

> 
>>> +ExecStartPre=/bin/udevadm settle
>> Please don't run udevadm directly. This is a udev command.
> 
> Can you please describe what will be broken by this?

The more important question is: what are you trying to fix with this?
The cryptsetup.target will only be active once all hooked up devices are
ready. There is no point adding a udevadm settle. That is purely useless.
So again, what are you trying to do/fix here?

>> Wants=systemd-udev-settle.service
>> After=systemd-udev-settle.service ...
>> (as the original .service file does).
> 
> The generated service files uses both variants:
> - The pre-cryptsetup and pre-local-fs services uses
>   systemd-udev-settle.service.


> - The pre-remote-fs service, which is not included here currently, uses
>   ExecStartPre.

You don't include that service. And also, just because
pre-remote-fs.service uses the ExecStartPre hack is no justification for
using that in lvm2.service. pre-remote-fs.service is a completely
different beast.

If you need more information, please ask. But please don't cook up your
own patch just for the sake of it. This bug has been open for far too long.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#727708: upstadt vs. systemd: events vs. dependencies

[Colin Watson]

On Wed, Jan 22, 2014 at 09:36:50AM +0100, Vincent Bernat wrote:
> I particularly hate the last one that bite me several times: you make
> one mistake ("expect fork" instead of "expect daemon") and you need to
> either reboot your system or know this script:
> 
>  https://github.com/ion1/workaround-upstart-snafu
> 
> Colin proposed to never use "expect fork" and "expect daemon", but they
> exist and our users will write Upstart jobs to start their scripts,
> daemons, workers, etc.

Allow me to elaborate slightly: my preference here would be to change
all existing jobs so that those two expect verbs are no longer needed,
and then compile them entirely out of Upstart.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140122091759.ga2...@riva.ucam.org

Bug#727708: upstadt vs. systemd: events vs. dependencies

[Vincent Bernat]

 ❦ 21 janvier 2014 14:00 CET, Lucas Nussbaum  :

> At this point of the discussion, stating that "one aspect didn't get the
> attention it should get." sounds a lot like "I didn't bother to search the
> archives". :-)

The fact that Upstart's proponents didn't outline important bugs in
Upstart may also been seen as "one aspect didn't get the attention it
should get". In the different final positions of the TC in favor of
Upstart, we don't see mentions of those important bugs:

 https://bugs.launchpad.net/upstart/+bug/516713
 https://bugs.launchpad.net/upstart/+bug/447654
 https://bugs.launchpad.net/upstart/+bug/406397

As Matthias, I wanted to point those out since a long time: how can we
choose Upstart when there are critical bugs that remain unfixed for
years?

I particularly hate the last one that bite me several times: you make
one mistake ("expect fork" instead of "expect daemon") and you need to
either reboot your system or know this script:

 https://github.com/ion1/workaround-upstart-snafu

Colin proposed to never use "expect fork" and "expect daemon", but they
exist and our users will write Upstart jobs to start their scripts,
daemons, workers, etc.
-- 
 /* Am I fucking pedantic or what? */
2.2.16 /usr/src/linux/drivers/scsi/qlogicpti.h


signature.asc
Description: PGP signature