(I wonder about the extent to which this remains on-topic... I didn't hesitate about my previous post, since it was relatively brief and addressed what I thought was an important and relevant single point, but this is considerably longer and gets rather farther afield.) On 10/27/2014 at 11:54 PM, Russ Allbery wrote: > The Wanderer <wanderer@fastmail.fm> writes: > >> Just as a note, one difference here is that there is support in >> the archive and package-distribution mechanisms for having multiple >> versions of a package for different architectures or (I think?) >> kernels, so that you can build a version with some optional >> features for one architecture / kernel but a version without those >> optional features on another - but there is no such support for >> having multiple versions of a package for different init systems. > >> You can only have one architecture, only one kernel, and only one >> init system active at any given time. The archive and its >> infrastructure recognizes this for architectures and (I think) >> kernels, and supports special handling for them to avoid or work >> around problems which would (or easily could) otherwise be present. >> The archive and its infrastructure do not presently recognize this >> or provide such support for init systems; as such, no such >> workarounds are available. > > *looks at his packages that support systemd, upstart, and sysvinit* > I think you're confused about where the hard parts of this process > are. > > It's often easier to support multiple init systems in a package than > supporting multiple architectures or multiple kernels. It's > certainly nothing that tremendously difficult to do. What sort of packages are these, and what sort of support is involved? What I'm thinking of is cases where upstream has decided to depend on functionality that is provided by one init system but not by others, without graceful runtime fallback - compile-time choices, essentially, where functionality is omitted if the init system is not present. I have had the impression that GNOME is one such upstream, to whatever extent it has not dropped support for non-systemd environments entirely. If adding support for other init systems to such packages (so that they do not assume the presence of certain functionality in the environment, but either can provide it themselves, or will simply fall back to not providing certain features if that functionality is not present) is not difficult, then that's certainly a good thing - but that is not the impression I've gotten from the comments thus far. My comments were pretty much not at all about init scripts or their equivalents, which after all are only about starting or stopping whatever "service" is in question, but only about functionality provided to other processes by the running init system. > The packages that are causing all the controversy at the moment > aren't created by some sort of archive limitations, or even by a > breakdown of this process. The problem, rather, is that only one > init system (or at least one init system's infrastructure; I'm > counting logind as part of systemd here) supports some decidedly > non-trivial features that those packages use, and no one has provided > a supported implementation of those features for other init systems. > In other words, they're very much akin to ZFS on FreeBSD. And that's entirely my point: something which depends on a feature provided by a kernel or an architecture, such that it won't build / run properly on anything that doesn't provide that feature, can be packaged either so as to be compiled with support for the feature in environments which provide it and without support for it in environments which don't or so as to be available (package visible to the package manager) in environments where the feature is available and not in ones where it is not - but something which depends on a feature provided by an init system cannot AFAIK be packaged in a comparably varying way, with the current packaging infrastructure. I am sort-of attempting to propose a different model for expressing the dependency of these upstreams (and the resulting packages) on the functionality provided by one particular init system, one which might be able to more easily allow "package with dependency and with matching functionality" to coexist with "package without dependency and without matching functionality". > But we already have a reasonable workaround in the form of getting > the systemd component to work under sysvinit. That's a matter of providing the functionality under other init systems. I am talking about making it (relatively) easy to provide parallel versions of the package which work when the functionality is not available in the environment, and/or making it possible for a package to express its absolute dependence on the functionality in a way that does not have such unfortunate failure states. The latter may be addressed by systemd-shim (at least within environments which systemd itself supports, i.e. Linux), but the former is not. In the past, we have had two major things of which you can only have one, of which every system must have one, and which provide differing feature sets in a way which can matter at runtime: the running kernel, and the CPU architecture. (Well, I imagine you *could* have a system with multiple CPUs of different architectures, but that would be fairly difficult to engineer in the first place.) We have special cases in the infrastructure for both of those, to allow smoothly expressing loose vs. hard dependencies on them, and to allow varying functionality from one to another depending on what each supports. Now that we have a third such thing - the init system - I am suggesting that it might be reasonable to have a special case in the infrastructure for that, as well, for similar purposes. (There may be an argument that there are other such things already in place, without such special cases - libc, for example. However, AFAIK the runtime feature sets which those provide are far closer to being equivalent - for purposes of binary packages depending on them, anyway - than are those of the other things listed.) >> It seems possible that some of the problems potentially / arguably >> introduced by having features provided by only a subset of >> available init systems could be avoided or resolved by having >> multiple package versions for different init systems, > > There's no reason to do that if someone is willing to port it. You > can combine it all into one package trivially. I had to blink at this for a moment. Can you please confirm that you're saying that having e.g. a GNOME package (or package collection, interlinked by dependencies, since GNOME is obviously far more than one package) which is built with a dependency on logind for environments where the functionality of logind is available, and built without that functionality for environments where that functionality is not available, would be trivial? If that is indeed trivially possible, then it would appear I've greatly misunderstood either the power and flexibility of the Debian packaging model or the degree to the features for which GNOME depends on logind are dynamically (i.e., runtime as opposed to compile-time) optional. > That's not the hard part; the hard part is replacing the > functionality that the package relies on but which is only provided > by one init system. What I'm arguing is that with kernels and architectures, we can build packages differently depending on what functionality we expect to be available in the final environment - but with init systems, as far as I can tell we cannot easily build a single package in multiple ways depending on what init system we expect to have available. Or at the very least, we aren't doing it. About the only way I can think of to do that under the current system would involve having multiple binary-package names, one per different build config, with different assumptions about environment-provided features in each - and I would expect that that would quickly become either very complicated or very broken once another package starts depending on the one we're looking at. > That's why people are putting all that hard work into systemd-shim, > which lets one use the systemd logind component without running > systemd itself. Once that work is done, then packages that rely on > logind don't need to do anything particularly special. Except that it seems very plausible that systemd will keep adding such features, and systemd-shim will have to keep chasing systemd, and there will always be a lag in the implementation of the new features. (Unless there comes to be active cooperation between the shim people and systemd upstream, which I've seen no indication is likely.) Plus I think I saw a bug discussion whose result was that systemd-shim will depend on having systemd-the-package installed, so as to be able to call features which it provides, rather than implementing them independently... which would avoid some problems which have occurred as new features or other changes get implemented in systemd, but which would mean that you couldn't use systemd-shim "without running systemd itself". -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature