User: Password:
|
|
Subscribe / Log in / New account

A call for votes in the Debian init system discussion

A call for votes in the Debian init system discussion

Posted Jan 26, 2014 22:05 UTC (Sun) by joyuh (guest, #95216)
Parent article: A call for votes in the Debian init system discussion

I believe that anyone who is employed by Canonical or Red Hat, or that regularly does significant work on either the systemd or upstart projects should abstain (or preferably, be stripped of their voting rights in this case) due to obvious conflict of interest or bias.


(Log in to post comments)

A call for votes in the Debian init system discussion

Posted Jan 26, 2014 23:31 UTC (Sun) by Thue (subscriber, #14277) [Link]

The conflict of interest is much stronger for Canonical employees than for hypothetical Red Hat employees, since Ubuntu imports code directly from Debian.

Not to mention that systemd has much more distribution-diverse contributors than upstart, which is basically a Canonical-only project.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 0:07 UTC (Mon) by johannbg (subscriber, #65743) [Link]

Which is probably why systemd is on it´s way into LSB 5.0 [1] ( whenever that might get released ) while upstart is not which is an added plus in favour of systemd although I honestly dont know if any distro beside Red Hat and Suse cares about following or be in compliance with LSB since it seems to be tailored by and for those two enterprise distributions more or less.

It feels like these two company's needed an standard so they invented one and maintain it for their distributions which means it's outdated with everything else that's happening in the GNU/Linux ecosystem and that standard only gets updated when the enterprise distro's are releasing a new release ( which means 5.0 will be released just before RHEL 7 and RHEL 7 be in compliance with that standard ).

1. https://wiki.linuxfoundation.org/en/Uplift_Target

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 19:34 UTC (Mon) by dlang (subscriber, #313) [Link]

just like LSB mandates rpm as the packaging system and Debian based systems ignore this and use .deb

what the LSB mandates really doesn't matter much. In some ways I wish it did and people would package and support software to run on any LSB compliant distro instead of specific distros, but that hasn't happened yet and I have no reason to believe that this is going to change.

David Lang

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 19:55 UTC (Mon) by anselm (subscriber, #2796) [Link]

just like LSB mandates rpm as the packaging system and Debian based systems ignore this and use .deb

LSB does not mandate RPM as the packaging system for compliant distributions. It only mandates that it must be possible to install software packages that come in RPM format, which is not the same thing.

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 14:49 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Yes, there's the alien tool for debian. But it's widely perceived as a hack and nobody like to use it. And then we have “Gnome Apps”, which is yet another way to distribute applications that isn't properly integrated with the distributions. All this infighting is holding the linux ecosystem back.

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 15:51 UTC (Tue) by krake (subscriber, #55996) [Link]

> Yes, there's the alien tool for debian

That is one possible approach, but it has the disadvantage of making the LSB package a "system" package, i.e. the converted deb is installed like an actual Debian package.

A better approach is to have an RPM based and controlled tree, say in /opt/lsb.

the converted deb is installed like an actual Debian package.

Posted Jan 28, 2014 16:26 UTC (Tue) by Wol (guest, #4433) [Link]

Which is the entire point of the LSB. Why do you (the user) want to have to manage two different installer packages? I run gentoo - I don't want to have to know yum, or apt, or whatever other weird packager someone else may have come up.

I just want to "emerge" a package, and if that has to convert it from a .lsb that's not my problem. And when I want to get rid of it, I want to be able to "emerge -C", not remember some strange weird syntax.

Cheers,
Wol

the converted deb is installed like an actual Debian package.

Posted Jan 28, 2014 17:07 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Couldn't emerge have an --lsb flag which takes an RPM and just Do The Right Thing?

the converted deb is installed like an actual Debian package.

Posted Jan 29, 2014 1:38 UTC (Wed) by HelloWorld (guest, #56129) [Link]

So he says he doesn't want to learn a new syntax and you respond by... proposing a new syntax? You might think that over.

the converted deb is installed like an actual Debian package.

Posted Jan 29, 2014 3:04 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

He didn't say he didn't want new syntax (How else would you get features? ESP? Only on the third Tuesday of even months?). He wanted to "emerge" a package. So let emerge do it by letting it know you want LSB semantics.

the converted deb is installed like an actual Debian package.

Posted Jan 29, 2014 16:20 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> He didn't say he didn't want new syntax
So what's this then?

> I just want to "emerge" a package, and if that has to convert it from a .lsb that's not my problem. And when I want to get rid of it, I want to be able to "emerge -C", not remember some strange weird syntax.

the converted deb is installed like an actual Debian package.

Posted Jan 29, 2014 16:32 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

That was under an "if I want to remove it" conditional. The tool could certainly remember that the package installed was an LSB package at that point. If the package has an ".lsb" suffix, then implying --lsb would probably make sense, but if you have an LSB package with the same name as a system package and want the LSB one, what else are you going to do?

the converted deb is installed like an actual Debian package.

Posted Jan 30, 2014 0:03 UTC (Thu) by HelloWorld (guest, #56129) [Link]

He also said this:

> I just want to "emerge" a package, and if that has to convert it from a .lsb that's not my problem.

This implies that he doesn't want to be bothered with the difference between LSB packages and regular ebuilds at all.

> but if you have an LSB package with the same name as a system package and want the LSB one, what else are you going to do?
This sounds like a corner case. If two packages of the same name are installed, it should be possible to tell them apart by the version – I know this is possible with rpm. And if it's the same version, there's no point in installing both the repository and the lsb version in the first place.

the converted deb is installed like an actual Debian package.

Posted Jan 31, 2014 1:32 UTC (Fri) by Wol (guest, #4433) [Link]

Coming back late, but yes.

Emerge can cope quite happily with "emerge libreoffice", and also with "emerge libreoffice-bin". So if somebody packaged an lsb version, and a gentoo maintainer created a "libreoffice-lsb" package, then fine.

I would just use the syntax I've always used, "emerge libreoffice-lsb", and let the emerge magic look after actually getting the package onto my system.

THAT is the way lsb is supposed to work - the lsb format is actually a restricted set of rpm, that is known to work well with alien, so that distros that want a .deb can easily convert it and install it. So that debian/ubuntu/mint/whatever users don't have to learn rpm/yum/yast/whatever.

Cheers,
Wol

the converted deb is installed like an actual Debian package.

Posted Jan 28, 2014 21:32 UTC (Tue) by krake (subscriber, #55996) [Link]

> Which is the entire point of the LSB.

Not quite. The LSB is addressing 3rd party software vendors' needs of having a safe assumption on available ABIs and, I think, services.

> Why do you (the user) want to have to manage two different installer packages?

Sorry, misunderstanding.

What I meant was that the LSB packages would not be treated like distribution packages, since they are not.
When users install distribution provided software they assume certain quality criteria, e.g. being free of conflicts, files ending up in certain locations without packages overwriting each other, being signed by keys from a certain keyring, etc.

LSB packages are provided by third parties, they are do not run through the same compliance tests as system packages.

Therefore converting them and then treating them like system packages would not be wise.
However, that doesn't mean they can't show up in the installed software list just like something from the repository and be uninstallable there, etc.

Nice handling of LSB packages is easier for non-RPM distributions, because they can just associate the RPM MIME type with their LSB tool and users can simply install packages by means like "double click" or being presented with an install option in browsers.

RPM based distributions need to inspect the RPM somehow to make this distinction (unless the LSB RPM has its own MIME type of course)

the converted deb is installed like an actual Debian package.

Posted Jan 28, 2014 22:46 UTC (Tue) by vonbrand (guest, #4458) [Link]

At least in Fedora installed software tracks the repository it comes from. You can then select on this for commands like uninstall. In any case, most of this stuff (or something compatible) part of the base distribution.

the converted deb is installed like an actual Debian package.

Posted Jan 28, 2014 22:59 UTC (Tue) by krake (subscriber, #55996) [Link]

I am not quite sure what to make of that.

> At least in Fedora installed software tracks the repository it comes from. You can then select on this for commands like uninstall.

So the Fedora package manager can treat a download directory, DVD or USB media as a separate repository and apply different polices?

Does that include installing into a different prefix? Not needing write access to the system package database (so that it can be enabled for other users who should be able to install those 3rd party apps but not mess up the system)?

> In any case, most of this stuff (or something compatible) part of the base distribution.

Yes, I would expect that the LSB handler would come from the base distribution.
After all it needs to ensure that all system resources are set up correctly, e.g. $PATH including the LSB prefix, XDG variables being set to include it, etc.

the converted deb is installed like an actual Debian package.

Posted Jan 28, 2014 23:11 UTC (Tue) by vonbrand (guest, #4458) [Link]

Somepackages can be installed with another prefix, but they are rare among"normal" distribution packages. The extra hassle just isn't worth it.

the converted deb is installed like an actual Debian package.

Posted Jan 28, 2014 23:19 UTC (Tue) by krake (subscriber, #55996) [Link]

Yes, but this was about LSB packages. Software provided by 3rd parties, without any guarantee on integration testing, etc.

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 17:38 UTC (Tue) by drag (subscriber, #31333) [Link]

> Yes, there's the alien tool for debian. But it's widely perceived as a hack and nobody like to use it.

If you look Debian does have RPM tool and can 'natively' install RPMs.

Since most of these third party rpms install to /opt like they are supposed to do there is usually no conflict.

A call for votes in the Debian init system discussion

Posted Jan 29, 2014 6:02 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

But it means that it would not identify file conflict with packages installed there as deb.

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 15:48 UTC (Tue) by krake (subscriber, #55996) [Link]

> since it seems to be tailored by and for those two enterprise distributions more or less.

That, i.e. enterprisee distributions, is indeed what it is targetting and it is pretty good at that.

An LSB version is basically a label that unified version of enterprise distributions. Hence it being defined by things already shipped by the two biggest vendors in that space.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 0:02 UTC (Mon) by misc (subscriber, #73730) [Link]

I fail to see the conflict of interest. In fact, the whole idea seems quite wrong to me. If people think that Canonical employees have a bias to make Debian adopt upstart, then what about the contrary, ie pushing Debian to not adopt Upstart in order to keep a competitive edge against a potential concurrent distribution ?

So since whatever they say could be constructed as resulting from bias, maybe the whole idea of having a bias is a invention without real causes.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 10:43 UTC (Mon) by HelloWorld (guest, #56129) [Link]

> I fail to see the conflict of interest. In fact, the whole idea seems quite wrong to me. If people think that Canonical employees have a bias to make Debian adopt upstart, then what about the contrary, ie pushing Debian to not adopt Upstart in order to keep a competitive edge against a potential concurrent distribution?
This is obviously nonsense. If they wanted a “competitive edge”, they wouldn't have published Upstart as Open Source in the first place. The fact that they support proprietary drivers and 3rd party programs and that they still haven't published the source code to the Ubuntu One server clearly indicates that they don't have any problem with keeping their stuff proprietary. Getting Upstart into Debian would clearly save them a lot of maintenance work as most of that work would henceforth be done upstream.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 0:41 UTC (Mon) by rodgerd (guest, #58896) [Link]

This is a really poor idea.

Debian shouldn't be sending the message that experts in a particular field aren't welcome to participate in technical committees. Otherwise you'd have the farcical situation that when the question inevitably comes up (as it will in a few years) around whether X sould be replaced as the default, you'd prevent Keith Packard being involved.

Also it's worth noting that the only behaviour that's seemed to me, as an outsider, spectacularly inappropriate during this debate has been Ian Jackson with nonsense like his "if we adopt systemd here's the resolution to declare Lennart a big fat poopy head that goes with it". But Ian isn't a Canonical employee.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 14:51 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Isn't Keith Packard involved with Wayland and be all kinds of +1 for a replacement? It's when people state that nothing could change their mind that their vote needs to be ignored. Here's something that would be enlightening, I think, to ask the TC members: what would it take for you to choose the other system as the blessed PID 1?

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 17:40 UTC (Tue) by drag (subscriber, #31333) [Link]

> Isn't Keith Packard involved with Wayland and be all kinds of +1 for a replacement?

Yes. Keith Packard has been a core Xorg developer for decades.

Most Wayland developers are also Xorg developers.

> It's when people state that nothing could change their mind that their vote needs to be ignored.

Maybe the reason they won't change their mind is because they are right?

A call for votes in the Debian init system discussion

Posted Jan 28, 2014 17:54 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

> Most Wayland developers are also Xorg developers.

I missed "also" in my comment. I'm aware of the overlap; just not to what extent exactly (e.g., I saw no commits by Keith in wayland repos) :) .

> Maybe the reason they won't change their mind is because they are right?

While they may not change their mind as things are now, what is the list of things that systemd would need to do to make Ian Jackson happy[1] (e.g., FreeBSD kernel support, support for an external cgroup manager)? What is the list of things upstart would need to do to make Bdale Garbee happy with it[1] (e.g., fix design flaws, fork into a non-CLA project)?

If the lists are empty then there's no sense including that person in the discussion since they'll never change their mind. If there is a list, you can focus on the relative merit of the items and why they might be more or less important than they are perceived to be in an effort to convince them of the other viewpoint.

[1]I'm not presuming these reasons would be on their list, just that they're something that someone might think is vital for a new PID 1.

A call for votes in the Debian init system discussion

Posted Jan 27, 2014 16:32 UTC (Mon) by anselm (subscriber, #2796) [Link]

There's nothing wrong with having the Canonical people participate in the tech-committee discussion. They could, for example, point out technical problems in systemd or explain perceived technical shortcomings in Upstart and why they are not relevant to the question at hand. (Not a lot of that has actually been happening during the discussion, in favour of mud-slinging against the systemd maintainers and promises of what one might possibly add to Upstart to make it more like systemd, but that's neither here nor there.)

Whether the Canonical people should actually vote on an issue that is as fraught with conflict-of-interest as this is a completely different matter. The interesting observation is that the people on the committee who are in favour of systemd as the default, unlike the Upstart supporters, are not obviously affiliated with the systemd project but have apparently come to their preference based on the technical merits of the alternatives under discussion. If there were no (current or former) Canonical employees on the committee at all, the issue might be much less contentious than it seems to be.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds