The Wanderer <wande...@fastmail.fm> writes: > Is it? I thought part of the problem is that there are packages whose > upstream supports (or at least enables) compiling with / without > integration to functionality provided by systemd, and which are provided > in Debian only as compiled with that functionality enabled, with no > alternative package which omits that functionality. I had the impression > that GNOME was one such (set of) package(s).
See Josselin's reply on this. You in theory can build GNOME with ConsoleKit support, but in terms of getting a generally working experience for the user, it's probably less work to get systemd-shim working with logind than to bring the ConsoleKit code up to snuff and support it. (Although apparently someone is trying the latter, so maybe this will change.) Either way, this isn't a simple matter of the package maintainers switching some flags, so adding more packaging tools doesn't really help. In other words, I think you're trying to solve the wrong problem. The problem you're trying to solve is not the obstacle that's getting in the way of good support for multiple init systems. > How does software which requires the features of a particular kernel > currently depend on having that particular kernel active? I would have > expected it to be via a dependency on 'linux-image' or 'kfreebsd-image' > or the like, but at a glance I don't see my current linux-image-* > package providing any such virtual package, and offhand I don't know of > any kernel-dependent packages except for systemd - which does not > obviously appear to express any kernel-related dependency. There are a ton, but because Debian architectures encode choice of kernel, they're represented in the archive as packages that are not available for kFreeBSD or Hurd, or only available for kFreeBSD, or only available for Hurd. A better example to look at if you want to see the problem handled via dependencies would be how Kerberos packages in the archive are handled, where basically everything is built with MIT except for a small number of packages linked with Heimdal. Or at the situation with OpenSSL and GnuTLS. > I thought I'd adequately allowed for both sides of that? The "software > that has been ported" would fall under "can be packaged so as to be > compiled with / without support", and the "software that has not been > ported" would fall under "can be packaged so as for the package to be > available when the functionality is and not when the functionality is > not". Is that not enough? Yeah, I had missed the second part, sorry. I think this is part of the question about how to handle installing a leaf package that only works with systemd. Ideally, if people have the time and energy to keep maintaining things like systemd-shim, we avoid this problem. It's rather surprising to have the init system changed by installing a package, but it's also surprising to have the package not appear available in apt until you reboot into a different init system (which I think is what you're proposing). That doesn't really make sense to me. What we may end up with is having packages be installable but not actually work, which is another less-than-ideal approach, but which I'm pretty sure we currently do with various other things in the archive with similar requirements that are hard to represent with dependencies. > udev and possibly the MTA is a point, but if you can only have one libc > installed at a time, that's news to me. Certainly any given program can > link with only one, and some programs may not work with some libc > implementations, but I wouldn't have intuitively expected having a > second libc installed separately (and linked against by whatever you > want to compile against it) would be a problem... You can install a second libc, but nothing uses it, and you can't load any shared libraries in programs built against it without rebuilding all of those shared libraries. So, effectively, you can install it but you can't use it for anything other than completely isolated development, at which point you may as well just use a chroot. I think it's fair to say that you can only have one libc. > As to the compiler, I either have to disagree with you, or misunderstand > what you're talking about. It's certainly possible to have multiple > compilers installed and functional side-by-side on a single machine, you > just can't have more than one of them set as 'cc' or the equivalent - > which is just a matter of the per-invocation default, really, rather > than a system-wide exclusive configuration. That even seems to be mostly > supported, at least as far as multiple versions of gcc. I was talking more broadly about places where Debian picks just one of something. I see you were talking specifically about what can be installed on a single system; in that case, yes, you can easily install multiple compilers. You can also easily install multiple init systems, but the system can only be booted with one of them at a time, which means init systems coexist *better* than libc, but worse than compilers, and a little worse than MTAs since you can switch MTAs without rebooting. >> With all of those facilities, we've taken different approaches; with >> the mail transport agent, for example, we've defined an interface that >> all mail transport agents are required to implement, and MTA >> implementations that don't implement that interface aren't allowed to >> provide a mail transport agent. We did something similar with /bin/sh. > Something like this might not be a bad idea for the init system, as > well. Though settling on something that wouldn't be at least as > controversial as the current flap might well be prohibitively difficult. Exactly. >> It was quite controversial when it first showed up, but it was so >> vastly, obviously superior to the solutions that we had available >> before then that it was widely adopted upstream and by packagers in the >> archive. Some people were quite upset and frustrated that they >> couldn't easily run systems without udev, but no real competitor to >> udev ever materialized. > This seems to make the same assumption that seems to have been made in > some of the pro-systemd arguments: that the problem is with the > implementation, not with the idea of doing it at all. In the case of logind, the people I've seen arguing that it shouldn't have been done at all pretty clearly didn't understand the problem space. Note that everyone is adopting logind, both upstream and among distributions. Ubuntu even was when planning on staying with upstart (which is where systemd-shim came from in the first place). I'm sure it's possible to do better than logind, but logind was a clear improvement over what DEs were using to solve those problems prior to logind. logind is the source of the (erroneous, although understandable) idea that the systemd ecosystem is more attractive for desktops than for servers. It turns out that systemd just as compelling for servers as for desktops when you take a good look at it, but logind is such an obvious win for desktops that it created that idea. > "If you don't like X, do the work to implement an alternative / > competitor" does not seem to take into account that "this isn't needed > or desirable at all!" perspective, for which there does not seem to be > any work which could be done. This is for obvious reasons, no? If something isn't required at all, people don't start using it, and people certainly don't get so excited about it that they push hard to adopt it broadly and start getting unenthused about working on systems that don't have it. So "this isn't needed or desirable at all" is an argument that can be easily dismissed simply by looking around and seeing the number of people who are excited about the new features and eager to adopt them. Specific individuals may well have no use for those features, but the general statement that *no one* wants those features is clearly and obviously false. Take a step back from this particular debate and look at the broader history of the IT field. How many times have we seen a company or an "industry leader" respond to the invention of something new and popular (usually by a competitor), or some limitation in existing software or hardware people are complaining about, with a statement like "no one will ever need that or care about that?" What's their track record in being correct? One thing that never works is claiming the excited and eager users of some new software or product don't actually exist or, even more insultingly, are all deluded. Unsurprisingly, people don't respond well to being lectured paternalistically on how they don't actually want something they clearly want. At best, they simply ignore you and move on. [udev] > It's my understanding that there are still people who still dislike it, > for the same reasons as initially - they just don't speak up, because > the battle is long since lost. There are always people who dislike any piece of software because all software sucks. I think the more relevant question is whether the software sucks enough that anyone will bother to go to the effort of replacing it. If the answer is no, I would argue that the software is not actually *controversial*, although it might be irritating or frustrating or even buggy. Some problems are hard or annoying to work on, and in those cases it's not unusual to settle on something that few people are particularly *excited* about, but which works well enough that it's not worth the effort to go replace it. > I think that's at least in part because the alternative (push back on > upstreams to not require logind, or to do so only optionally, with > runtime fallback) is seen as completely futile, especially without the > support of a distro as backing. That's not a reason; that's just moving the question to a different set of people. Why are the upstreams dubious about investing the effort into supporting non-logind configurations? Either you have to go down the mental path where you start inventing a massive conspiracy that somehow involves alliances between projects that are openly competing, or you have to come to terms with the fact that maybe logind is really compelling for people who work in this space and understand the problems that it's solving. > I think that's probably a large part of the motivation of those who want > Debian to formally support multiple init systems (in the sense > underlying this GR): to be able to have Debian's weight behind efforts > to persuade upstream to support such cross-init-system interoperability. I know that it is, but I find that baffling, since from where I sit such a thing is clearly absurd and useless. Since when are free software projects convinced by louder and more demanding voices rather than technical arguments? The way to get upstreams to support cross-init-system interoperability is for someone to join the upstream project, write that functionality in a supportable way, and maintain it. Olav Vitters from the GNOME project has been interacting on Debian mailing lists for a while now, practically *begging* for people to engage with him and with the GNOME developers and explain exactly what requirements they see and how they want to address them. I suspect the lack of meaningful response has gotten rather frustrating. If people want to talk to GNOME developers, they've been openly inviting such conversation for years now. You don't need a GR, you don't need leverage, you just need to go talk to them and do enough research in the relevant technical space to have intelligent and reasonable things to say. On this front, I recommend reading what Olav wrote on this topic if you haven't already. I think it makes fairly clear what is going through the head of upstreams here: http://blogs.gnome.org/ovitters/2014/09/07/systemd-in-gnome-3-14-and-beyond/ I would particularly like to emphasize this statement, which I think is an accurate summation of most of the arguments I see: If a project sees functionality within systemd that is useful, it is. [Y]ou'll not get very far with stating that the project is bad for having used that. Or suggesting that there is some conspiracy going on, or that the project maintainer is an idiot. That's unfortunately often the type of "anti-systemd advocacy" which I see. and: Projects have depended on systemd because it does things which are useful. As a person you might not need it. The other one believes he does need the functionality. Saying "I don't" is not communication. At least ask why the other believes the functionality is useful! > systemd-shim 8.2 and 7.1 do not list a dependency on systemd, or appear > to invoke one indirectly; as far as I recall, no such dependency had > previously been present, either. Attempting to install systemd-shim and > remove systemd in a --dry-run does not complain. That's because the point of systemd-shim is to provide the services that logind requires without running systemd as PID 1, so that packages can then depend on logind without requiring systemd be PID 1. That didn't require a direct dependency on systemd because that dependency comes in via libpam-systemd or some other route in the software using logind. In other words, the whole point of systemd-shim is to enable the use of logind. It's not replacing it with something else. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87egtl5cck....@hope.eyrie.org
