Bug#947847: please install systemd-sysusers using update-alternatives
On 2/21/20 9:10 PM, Niko Tyni wrote: > Hi Thomas, > > on IRC recently you said: > > 23:24 < zigo> If you're just answering about update-alternatives, then you > haven't paid attention to what I >wrote in the bug report. > 23:25 < zigo> And IMO, missing the point ... > > As I read the above, the systemd maintainers declined your suggestion to > add support for handling /usr/bin/systemd-sysusers with the alternatives > system, and you then requested the Technical Committee to overrule them. > > If this is not the case, could you please state clearly what you want > us to decide. > > Among other things, you later mention that a separate systemd-sysusers > package would be acceptable to you, pointing to #946456 . This avenue > doesn't seem to be exhausted yet? Hi, IMO, the question is a bit more hard than just "having packages that conflicts" or "using update-alternatives". As I think the issue is complicated, I would have like to have the tech ctte opinion on how to handle this case, for the Debian project at large. This is a general opinion that I'm asking for here, and guidance on how to set the policy for programs using systemd-sysusers, and the ones willing to (re-)implement the systemd interface to be used as an alternative implementation. It is my opinion that it's not good enough for the maintainer of systemd and systemd-sysusers to just decide, as every program using sysuser may be affected. Also please keep in mind that this is not only about sysusers, but a more broad scope (tmpfiles is concerned too... more may come!). Using update-alternatives for /bin/systemd-sysusers is what I thought was the best option, because cheap and easy to implement, with the nice advantage that we can have both packages installed at the same time, and programs can decide if they want a specific implementation or just any of them. However, if everyone is in the opinion that it's a bad idea, then I'm open to other solutions. Having systemd package systemd-sysusers (and systemd-tmpfiles) as separate package is also an option that would work. It's IMO annoying, because it takes a way longer to switch from one implementation to another, when update-alternatives instantly changes the configuration. We also loose the co-instability, and the fact that a given program can actively decide to use a specific implementation. But that still works too. However, packaging systemd-sysusers as a separate package it isn't as easy as one may think. See #946456 for the discussion. Using update-alternatives should have been a way easier. At the present moment, I'm not aware of any decision from the systemd maintainer, as this looks like not as easy as one may think. The only thing which I do *not* want to do, is using dpkg-divert. It is my strong opinion that this is a disservice to our users to do that, because dpkg-divert is rarely known, yet even understood by the average Debian users, so they wouldn't be able to even understand what happened to their system. We should be able to find a much nicer way to implement things. I'm also strongly against a /bin/sysusers which both programs would update-alternatives to, because then, we have a different implementation than on other platforms (this would be Debian specific). Cheers, Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
(Sorry for the extensive quoting, see the end.) On Mon, Jan 27, 2020 at 11:18:53AM +0100, Thomas Goirand wrote: > On 1/25/20 5:05 PM, Michael Biebl wrote: > > Control: tags -1 + wontfix > > > > On Tue, 31 Dec 2019 17:29:29 +0100 Thomas Goirand wrote: > >> Package: systemd > >> Version: 244-3 > >> Severity: important > >> > >> Hi, > >> > >> As I'm packaging opensysusers (see ITP: #947846), I would like my > >> package to also provide /bin/systemd-sysusers. Please install this > >> binary on another location, so that both systemd and opensysusers can > >> implement it. I am very much fine to have systemd have the priority over > >> opensysusers if you believe it should (I'm open to discussion about > >> priorities). > > > > Thanks for your interest in systemd-sysusers. > > After thinking more about this, I don't consider renaming > > systemd-sysusers and installing it via alternatives as a good idea. > > > > When systemd is installed and used, we definitely want to use its own > > implementation. > > > > My recommendation would be to install the opensysusers implementation > > under a different binary name. > > > > Alternative init systems can then decide to support sysusers by calling > > that opensysusers binary during boot. > > debhelper, should it get sysusers support, should generate code which > > calls the correct binary depending on the current circumstances. > > > > Regards, > > Michael > > > > > > > > Hi Michael, > > It is my view that what you're proposing would be a lot more work for on > valid reason. I'm therefore re-assigning the bug to the tech-ctte, > asking them to decided instead. > > It is my view that using update-alternatives is *very* easy to > implement, so that we can share the /usr/bin/systemd-sysuser location. > > Besides the fact that, with the way you're suggesting, we'd need to fix > debhelper (which I don't think is reasonable, as it wont be the only > place to handle multiple cases, I'm foreseeing...), there's also the > concern that you don't seem to agree that it'd be ok for one to use > opensysuser instead of the systemd implementation if systemd is running. > I do not agree with this, and I believe it is up to the users to decide > what to do, even if we, as an operating system, must provide sensible > defaults (which also can be discussed, but that's not the point of this > bug report). > > Moreover, I don't see why /usr/bin/systemd-sysusers would be any > different from let's say /usr/bin/awk. The update-alternatives system is > there exactly to handle the case we're facing today. > > So, tech-ctte, please decide. > > Cheers, > > Thomas Goirand (zigo) Hi Thomas, on IRC recently you said: 23:24 < zigo> If you're just answering about update-alternatives, then you haven't paid attention to what I wrote in the bug report. 23:25 < zigo> And IMO, missing the point ... As I read the above, the systemd maintainers declined your suggestion to add support for handling /usr/bin/systemd-sysusers with the alternatives system, and you then requested the Technical Committee to overrule them. If this is not the case, could you please state clearly what you want us to decide. Among other things, you later mention that a separate systemd-sysusers package would be acceptable to you, pointing to #946456 . This avenue doesn't seem to be exhausted yet? -- Niko Tyni nt...@debian.org
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/30/20 8:18 PM, Anthony DeRobertis wrote: > On 1/30/20 7:02 AM, Thomas Goirand wrote: >> This is normally solved if using pre-depends, which ensure that a >> package is configured before using it (and not just unpacked). > > Having everything using sysusers have versioned Pre-Depends on systemd | > opensysusers would probably minimize the problem, but could potentially > be a fair number of Pre-Depends to add. (I have no idea if non-versioned > Pre-Depends on a virtual package works, if so that'd be better. If not, > it'd also require adjusting them all if another alternative is introduced.) I wrote that it could be a solution to the said problem, but I am really not convince there's a problem at all. Thomas
Bug#947847: please install systemd-sysusers using update-alternatives
On Mon, Jan 27, 2020 at 06:16:14PM +0100, Svante Signell wrote: > It is as simple as: > if ps -p1|grep -q "systemd"; then This is not the correct way to detect whether systemd is the current init system. You want: if test -d /run/systemd/system; then See https://www.freedesktop.org/software/systemd/man/sd_booted.html > > else > > fi "exec", not "install". - Josh Triplett
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/30/20 7:02 AM, Thomas Goirand wrote: This is normally solved if using pre-depends, which ensure that a package is configured before using it (and not just unpacked). Having everything using sysusers have versioned Pre-Depends on systemd | opensysusers would probably minimize the problem, but could potentially be a fair number of Pre-Depends to add. (I have no idea if non-versioned Pre-Depends on a virtual package works, if so that'd be better. If not, it'd also require adjusting them all if another alternative is introduced.) I'm not sure what the risk of dependency resolution unexpectedly changing a system to use opensysusers is. Or of it deciding to install systemd when the admin wants to use opensysusers — that is probably a higher risk since systemd would be listed as the first alternative. Not saying any of this is a showstopper, of course, just that its a downside/potential complication to weigh.
Bug#947847: please install systemd-sysusers using update-alternatives
Le jeudi, 30 janvier 2020, 00.28:36 h CET Thomas Goirand a écrit : > On 1/29/20 4:31 PM, Didier 'OdyX' Raboud wrote: > > Software installed as /bin/systemd-* , created within the systemd project, > > to fulfill systemd's view of the world, takes a reasonable hit on the > > binaries' namespace: "systemd-*". Really, we should be thankful that the > > systemd project actually started using /bin/systemd-sysusers and not just > > /bin/sysusers. To extend on this, I think it's obvious that what the > > "systemd-sysusers" binary name _says_ really is "this is a > > systemd-specific utility". > > They probably should be thanks to save the namespace, however, they > shouldn't be for pushing for bundling many different things in a single > software. The way I look at this is: the "systemd software team" added a software they had a need (or a vision) for, and added it in their usual way: by adding it in their repository [0]. Then other projects noticed this new piece of software and found it interesting, hence started to use it, because it filled a need they had, or replaced older codepaths with this new tool. > Let's say I was proposing an alternative implementation of > /usr/sbin/adduser (note that it doesn't have a software name in its > path...), would you allow it? Hopefully yes, if it had the same > functionalities, plus some other properties and improvement (like not > being written in perl... :) I'm not sure whether you brought this example on purpose, because Debian already ships adduser (in perl), and useradd (in C). And the perl version is the enhancement of the C version. But they don't carry the same name. And this matters; it's a question of honouring interface promises. To answer your question directly: I don't think Debian should ever allow to pick between different /usr/sbin/adduser implementations, per system, no. But it could eventually be replaced, like we migrated to dash as /bin/sh: for Lenny it was possible to switch to dash as /bin/sh, for Squeeze it was enforced on all hosts. > Why is it controversial here? Because you're asking to replace a piece of software made by the systemd project, in the systemd repositories, shipped in the systemd package, knowingly used by other projects as being from systemd. What would be your stance as OpenRC maintainer if I asked you to add a update-alternatives for /sbin/openrc-run for my /sbin/pyopenrc-run? > Some of us have complained about the non-modularity of systemd. My idea > was to prove them wrong, and that we can replace some of the components > that aren't that tightly integrated. Please don't use the Debian archive (and project) to prove other projects wrong, really. > It feels like upstream also declares systemd-sysusers as an independent > component, and kind of agree with me on this specific point. What I read from the systemd project on [1] is "some of our software doesn't need to run on hosts with systemd as init". But what I understand from your position is "as some of the systemd software doesn't need to run on hosts with systemd as init, we can replace them with alternative software". If that's what you're saying, I don't think the conclusion follows from the observation. But holding the systemd software (and hence their Debian maintainers) up to their promises (as is done in #946456) is a very good way to go, and a burden I feel is reasonable on the systemd maintainers' shoulders. Once, and if that is sorted out, packages would need to amend their dependencies to depend on systemd-sysusers; opensysusers could then Conflict/Provides systemd-sysusers for example; all this without the need for update-alternatives. (I'd also argue that providing systemd-sysusers in its own binary package [or systemd-utils] mostly makes opensysusers purposeless.) > I'm simply asking *Debian* (not systemd maintainers) to allow multiple > implementations of the same functionality (ie: adding users using a data > file format, which happens to have been invented by the systemd project). It's already possible; maintainers can use opensysusers _now_. > > My answer to this is that /bin/systemd-sysusers _is_ a systemd interface, > > with a systemd-* name > > The binary name is very deceptive and annoying. I wished it was packaged > and maintained separately, because it has very little to do with an init > system. It seems you're reading systemd-* to say "comes with systemd the init system", where I read "systemd-*" to say "comes from the systemd project". As I said earlier, we should be _glad_ that the systemd project innovates in their space using their namespace. Just imagine for a second if they had used /usr/sbin/adduser (because that's what it does, right?). > > Please let's not use this as a point of argumentation. You can't just dismiss my points because you don't agree with them. I stand to thinking this point is central: if the systemd package had started shipping /usr/sbin/sysusers, you would have a _much
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/30/20 7:16 AM, Anthony DeRobertis wrote: > There are some more that come to mind: > > * if we convert the exiting name to an alternative, there is the > somewhat interesting work of actually changing a file over from an > executable shipped in the package to an alternative, which would > normally be set up by postinst. That could leave an uncomfortably > large window during upgrade where the system would be broken (and > possibly not boot) if interrupted. This is normally solved if using pre-depends, which ensure that a package is configured before using it (and not just unpacked). > * if we use a new, different name, then we've introduced a > Debian-specific interface. One of the nice things about most of the > Linux world standardizing on systemd is increased cross-distro > compatibility; here we'd be breaking it. That's exactly what made me think that using the original name was less Debian wide work indeed. Though because of the binary name prefixed with "systemd-" this is less elegant than standardizing on /bin/sysusers. Cheers, Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
Svante Signell writes: > On Wed, 2020-01-29 at 12:23 -0800, Moritz Mühlenhoff wrote: >> Simon McVittie wrote: >> > I think we have a fairly good picture of the costs that would be >> > incurred from using alternatives: >> >> Plus in the case of opentmpfiles; a pile of security issues: systemd- >> tmpfiles addresses a number of complex races using low level >> primitives like openat() et al. or O_PATH, while opentmpfiles is >> implemented in shell. > > Do you mean that shell scripts cannot cannot handle such issues?? If you are asking that question, then I suspect that your knowledge of the problems of shell scripting may be sufficiently limited to mean that the only useful way to answer it would be to say: Yes. > So C-code is safe by construction, do you really believe in that? What a ludicrous question -- well done for surpassing the previous one. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 2:19 PM, Simon McVittie wrote: I think we have a fairly good picture of the costs that would be incurred from using alternatives: more interacting code paths to test, potentially more configurations that are technically possible but are not considered supported, and packages with "Depends: systemd (>= 321)" (or indeed systemd itself, in the case of systems using it to boot) not being able to rely on having access to all systemd 321 features, which doesn't seem like a least-astonishment situation to be in. However, Michael, or anyone else opposing this change: if you have anything to add to those, please do. There are some more that come to mind: * if we convert the exiting name to an alternative, there is the somewhat interesting work of actually changing a file over from an executable shipped in the package to an alternative, which would normally be set up by postinst. That could leave an uncomfortably large window during upgrade where the system would be broken (and possibly not boot) if interrupted. And, unlike the related dpkg-divert challenge, this would be on the vast majority of Debian systems, not only those where opensysusers is installed. * if we use a new, different name, then we've introduced a Debian-specific interface. One of the nice things about most of the Linux world standardizing on systemd is increased cross-distro compatibility; here we'd be breaking it. * regardless of which name (existing or new), alternatives can wind up pointing at nothing during the upgrade. Or if the upgrade is interrupted. I seem to recall that's one reason /bin/sh was never an alternative; seems like there is a cost in increased fragility (again, on all systems, not just ones with opensysusers).
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 8:19 PM, Simon McVittie wrote:
> - Linux systems not booted with systemd
> (either no init system at all, like a typical schroot or Docker
> container, or a non-systemd init system like sysvinit)
This is very much one type of systems I have in mind, yes, and
open{sysusers,tmpfiles} could help to make them smaller. Just pulling
the whole systemd stack to add system users seems too much for very
little benefits.
> I think we have a fairly good picture of the costs that would be
> incurred from using alternatives: more interacting code paths to test,
> potentially more configurations that are technically possible but are
> not considered supported, and packages with "Depends: systemd (>= 321)"
> (or indeed systemd itself, in the case of systems using it to boot)
> not being able to rely on having access to all systemd 321 features,
> which doesn't seem like a least-astonishment situation to be in. However,
> Michael, or anyone else opposing this change: if you have anything to
> add to those, please do.
We don't need to do "Depends: systemd (>= 321)", we could have a virtual
package provided by both implementations.
Cheers,
Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 4:49 PM, Didier 'OdyX' Raboud wrote: > Le mercredi, 29 janvier 2020, 16.07:21 h CET Thomas Goirand a écrit : >> This reasoning can make sense, if we agree that we should use something >> else than /bin/systemd-sysusers and standardize on something else like >> /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is >> *the* way to do things, and using /bin/systemd-sysusers becomes a bug of >> severity "serious" (policy violation). > > We'd first have to agree that an alternative is actually _needed_. And so > far, > the only arguments I have read in favour of providing alternatives to > /bin/systemd-sysusers are: > * A) it is shipped in the systemd binary package; > * B) Having competing implementations is important; > * C) it comes from the systemd project; > * D) it has a systemd-* name; Very much, B for me... I don't want to see Debian stuck in a position where we are locked-in. This is my main motivation. C and B are distractions that I'm not at all diving into. A is annoying, because that imposes micro-packaging on systemd maintainers (a 200k+ package for just this simple feature? really?), and we try to avoid this project-wide. Thomas
Bug#947847: please install systemd-sysusers using update-alternatives
Hi Didier!
Thanks for taking the time to reply.
On 1/29/20 4:31 PM, Didier 'OdyX' Raboud wrote:
> Software installed as /bin/systemd-* , created within the systemd project, to
> fulfill systemd's view of the world, takes a reasonable hit on the binaries'
> namespace: "systemd-*". Really, we should be thankful that the systemd
> project
> actually started using /bin/systemd-sysusers and not just /bin/sysusers. To
> extend on this, I think it's obvious that what the "systemd-sysusers" binary
> name _says_ really is "this is a systemd-specific utility".
They probably should be thanks to save the namespace, however, they
shouldn't be for pushing for bundling many different things in a single
software.
Let's say I was proposing an alternative implementation of
/usr/sbin/adduser (note that it doesn't have a software name in its
path...), would you allow it? Hopefully yes, if it had the same
functionalities, plus some other properties and improvement (like not
being written in perl... :) (just trolling here... hopefully we can have
fun in this discussion? :)).
Why is it controversial here? Maybe because upstream decided to bundle
it together with many unrelated components, as I wrote above, and prefix
the binary file name with the "systemd-" name, to give the impression
that it feels "integrated". Hopefully, you'll be able to enlighten me if
I forgot something else! :)
Some of us have complained about the non-modularity of systemd. My idea
was to prove them wrong, and that we can replace some of the components
that aren't that tightly integrated. It feels like upstream also
declares systemd-sysusers as an independent component, and kind of agree
with me on this specific point.
> Let's see if I understand what you want correctly; you want Debian to allow
> replacing systemd-specific software with alternatives, right?
It only your own opinion that systemd-sysusers is systemd specific. My
view is that what it does isn't more specific to systemd than
/usr/sbin/useradd, and that in the first place, it should have *never*
been part of a single systemd project. That's truth for many other
components of systemd, but let's not discuss this (it's out of scope).
Now that some are proposing that sysusers becomes a accepted Debian
interface, it becomes increasingly important that it becomes independent
from any other component of the system, and that it can be replaced or
reimplemented in a different way. Otherwise, maintainers scripts will
increasingly use it, and we become effectively locked-in, married
forever with systemd.
> I'm sorry, but
> this does not make any sense to me: /bin/systemd-sysusers _is_ systemd-
> specific, and is used as such by systemd.
I am contesting this.
It's bundled with systemd, yes. It's pre-fixed with the word "systemd-"
in its binary name, yes. The idea of the static sysusers data file comes
from systemd, yes. But it stops here.
Its core functionality isn't systemd specific. We've been adding systemd
users in maintainer scripts for decades, a long time before we even knew
the word "systemd".
> If usages of it have appeared
> outside of the systemd repository, I think it's fair to say (because of the
> binary's name)
The binary name is precisely a distraction which you should try to
ignore, because it is very misleading.
> that they were knowingly using a systemd-specific piece of
> software (and hence, have correctly added a "{Pre-,}Depends: systemd".
That is exactly what I would like to avoid. Hopefully, we will be able
to have:
{Pre-,}Depends: systemd-sysusers | opensysusers
or even:
{Pre-,}Depends: sysusers
if we get into the virtual package thing... And probably we should!
(maybe we can discuss this after this first discussion is done)
> If I reformulate what it seems to me you're asking, it comes accross to me as
> "/bin/systemd-sysusers comes from systemd and it should be possible to have a
> system without systemd installed, therefore please force the systemd
> maintainers to allow hosts to have a non-systemd /bin/systemd-sysusers".
I don't like *at all* the way you are reformulating, and that's not
really what I'm asking for. So please allow me reject the way you are
putting things, and let me phrase it my way.
I'm simply asking *Debian* (not systemd maintainers) to allow multiple
implementations of the same functionality (ie: adding users using a data
file format, which happens to have been invented by the systemd project).
To be able to allow another implementation to exist in Debian (which
happen to work anywhere, even without systemd, that's truth, but that's
not the only property of opensysusers), and a way in Debian so we can
standardize on.
This goes beyond the "I want to use sysusers in non-systemd setups". I
also want to be able to use opensysusers when I run systemd. In fact,
that's how I would like *my* own laptop / servers to run.
Anyway, there's a few ways to make this work, and both things to cohexist.
1/ Having a systemd-sysuser
Bug#947847: please install systemd-sysusers using update-alternatives
On Wed, 2020-01-29 at 12:23 -0800, Moritz Mühlenhoff wrote: > Simon McVittie wrote: > > I think we have a fairly good picture of the costs that would be > > incurred from using alternatives: > > Plus in the case of opentmpfiles; a pile of security issues: systemd- > tmpfiles addresses a number of complex races using low level > primitives like openat() et al. or O_PATH, while opentmpfiles is > implemented in shell. Do you mean that shell scripts cannot cannot handle such issues?? So C- code is safe by construction, do you really believe in that?
Bug#947847: please install systemd-sysusers using update-alternatives
Simon McVittie wrote: > I think we have a fairly good picture of the costs that would be > incurred from using alternatives: Plus in the case of opentmpfiles; a pile of security issues: systemd-tmpfiles addresses a number of complex races using low level primitives like openat() et al. or O_PATH, while opentmpfiles is implemented in shell. Cheers, Moritz
Bug#947847: please install systemd-sysusers using update-alternatives
Am Mi., 29. Jan. 2020 um 20:39 Uhr schrieb Simon McVittie : > [...] > I think there are three categories of systems that it might make sense > to consider separately here. In ascending order of "amount of systemd": > > - non-Linux ports to which systemd does not intend to be portable (and > I think we can treat non-systemd-by-policy derivatives like Devuan as > basically equivalent to these), where the systemd implementation of > -sysusers simply does not exist > > - Linux systems not booted with systemd > (either no init system at all, like a typical schroot or Docker > container, or a non-systemd init system like sysvinit) > [...] For this particular case it's probably worthwhile to also consider Zbigniew Jędrzejewski-Szmek's comment on debian-devel a while back, where they extended systemd's interface stability and compatibility promise based on our discussions back then. Namely: > Independent operation of a bunch of > programs is now explicitly covered, and the stability promise > has been extended to more interfaces. >From >https://systemd.io/PORTABILITY_AND_STABILITY/#independent-operation-of-systemd-programs systemd-sysusers and tmpfiles are covered by this promise, as well as a few other utilities. So, especially for container usecases it may actually be reasonable for the systemd maintainers to make those utilities available in a separate package to be installed without the daemon components. That way they would be readily available and working even on systems where systemd isn't PID1 (of course, the daemons should also be inert until an alternative init system starts to parse systemd service files, so at the moment even installing the systemd package itself for these binaries is safe). Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Bug#947847: please install systemd-sysusers using update-alternatives
Svante Signell dijo [Wed, Jan 29, 2020 at 08:15:36PM +0100]: > > It's not like having two competing implementations causes much > > harm here.we technically _can_ allow any /bin/systemd-* to be > > provided by another implementation, that we should (actually, I think > > we should clearly _not_). > > Of course the name should not be systemd-*. That would conflict with > systemd upstream, and a lot of other stuff too! Humh, where did you quote this snippet from? It includes bits from OdyX's mail, but it's wrapped over itself. It also shows as if it were my text (which is _not_). > > /usr/bin/systemd-* is clearly implementation-specific. Now, if we are > > to allow alternative implementations of /usr/bin/system-brewmycoffee, > > no way! Please keep on reading for the full paragraph... > > we should first push to an alternative /usr/bin/brewmycoffee, get the > > systemd maintainers to "subscribe" to it using our great alternatives > > system, and provide our /usr/bin/open-brewmycoffee. > > Why should they be subscribing? There are other people within Debian > who can provide alternatives. I tend to convey that, if Debian is to support more of one argument-compatible implementations of brewmycoffee (one of which is systemd-brewmycoffee), I feel the systemd maintainers should be sensible and allow its use, via the alternatives system, as /usr/bin/brewmycoffee. Of course, it is highly likely they will be seen as the reference implementation and others should attempt to adopt a compatible interface arguments-wise. > > And I think that now, that not so many packages have yet adopted > > systemd-derived facilities, is a great time to set this as a good > > practice. > > Is this your interpretation of the GR? It my impression, at least.
Bug#947847: please install systemd-sysusers using update-alternatives
On Mon, 27 Jan 2020 at 11:18:53 +0100, Thomas Goirand wrote: > you don't seem to agree that it'd be ok for one to use > opensysuser instead of the systemd implementation if systemd is running. > I do not agree with this, and I believe it is up to the users to decide > what to do, even if we, as an operating system, must provide sensible > defaults I hope everyone involved can agree that: - we should provide choices where their benefit exceeds their cost, because more choice results in a more widely applicable system; - we should not provide choices where their cost exceeds their benefit, because more guarantees result in a more robust system (By "cost" I mean developer time spent, avoidable bugs caused, etc. - not money.) To take some clear examples: at one end of the scale, we provide a way to configure per-system whether /usr/bin/editor is emacs or vi or whatever, because that's primarily about subjective, personal UI preference. At the other end of the scale, we *don't* provide a way to configure per-system whether /bin/tar is GNU or BSD tar: we want packages that run tar to be able to make the simplifying assumption that on any Debian system, it's going to be GNU tar, and we do not want to deal with bug reports from users who have switched to an unexpected tar implementation. So this is at least partially a question of whether making opensysusers vs. systemd-sysusers easily sysadmin-configurable has a cost greater or less than its benefit, or to put it another way, where it falls on a scale between /usr/bin/editor and /bin/tar. With that in mind: Thomas, or anyone else asking for this change, what benefits do you expect users of Debian to obtain from being able to install both opensysusers' implementation of the sysusers.d interface and systemd's, and choose which one is invoked from the boot procedure and packages' postinsts via configuration, as opposed to via package installation/removal? I think there are three categories of systems that it might make sense to consider separately here. In ascending order of "amount of systemd": - non-Linux ports to which systemd does not intend to be portable (and I think we can treat non-systemd-by-policy derivatives like Devuan as basically equivalent to these), where the systemd implementation of -sysusers simply does not exist - Linux systems not booted with systemd (either no init system at all, like a typical schroot or Docker container, or a non-systemd init system like sysvinit) - Linux systems booted using systemd It might be helpful to consider which benefits apply to which of these categories. For example, the first category certainly benefits from opensysusers *existing*, but does not directly benefit from co-installability or from having a choice, because there is no such choice: systemd's -sysusers is not available there, so using something non-systemd is the only option. I think we have a fairly good picture of the costs that would be incurred from using alternatives: more interacting code paths to test, potentially more configurations that are technically possible but are not considered supported, and packages with "Depends: systemd (>= 321)" (or indeed systemd itself, in the case of systems using it to boot) not being able to rely on having access to all systemd 321 features, which doesn't seem like a least-astonishment situation to be in. However, Michael, or anyone else opposing this change: if you have anything to add to those, please do. Thanks, smcv
Bug#947847: please install systemd-sysusers using update-alternatives
On Wed, 2020-01-29 at 12:24 -0600, Gunnar Wolf wrote: > It's not like having two competing implementations causes much > harm here.we technically _can_ allow any /bin/systemd-* to be > provided by another implementation, that we should (actually, I think > we should clearly _not_). Of course the name should not be systemd-*. That would conflict with systemd upstream, and a lot of other stuff too! > /usr/bin/systemd-* is clearly implementation-specific. Now, if we are > to allow alternative implementations of /usr/bin/system-brewmycoffee, no way! > we should first push to an alternative /usr/bin/brewmycoffee, get the > systemd maintainers to "subscribe" to it using our great alternatives > system, and provide our /usr/bin/open-brewmycoffee. Why should they be subscribing? There are other people within Debian who can provide alternatives. > And I think that now, that not so many packages have yet adopted > systemd-derived facilities, is a great time to set this as a good > practice. Is this your interpretation of the GR?
Bug#947847: please install systemd-sysusers using update-alternatives
I just want to subscribe with a very big +1 to what OdyX has said here: Didier 'OdyX' Raboud dijo [Wed, Jan 29, 2020 at 04:31:09PM +0100]: > (...) > > So I am in the opinion that "as long as it's properly hooked in the > > packaging system and boot sequence" simply doesn't work in this case, as > > systemd-sysusers could be called from virtually anywhere. > > That's exactly the point: if it's so good that it has become used in many > places, changing the binary behind the scenes is clearly premature at this > point. > > If I reformulate what it seems to me you're asking, it comes accross to me as > "/bin/systemd-sysusers comes from systemd and it should be possible to have a > system without systemd installed, therefore please force the systemd > maintainers to allow hosts to have a non-systemd /bin/systemd-sysusers". > > My answer to this is that /bin/systemd-sysusers _is_ a systemd interface, > with > a systemd-* name and I don't think it's reasonable to ask (or force) the > systemd maintainers to allow "their" interface to be implemented by other > software projects. Afterall, they came with the idea first, in their > namespace. > > That said, taking a step back and looking at the larger picture, if what you > wish is a Debian in which one can pick their preferred sysusers' > implementation, what about discussing the pertinence of a "parent" > /bin/sysusers; with alternatives' setup there? (I wouldn't be surprised if > the > systemd maintainers agreed to register /bin/systemd-sysusers as alternative > to > /bin/sysusers). > > With this in place, you could go to maintainers who _have_ already used > /bin/systemd-sysusers to try convince them to use the /bin/sysusers > "standard" > interface instead. We have this for 'httpd', 'default-mta', what about having > a virtual 'sysusers' ? > > All-in-all, I think the question you're asking is misguided: it's not because > we technically _can_ allow any /bin/systemd-* to be provided by another > implementation, that we should (actually, I think we should clearly _not_). > But not having a /bin/systemd-sysusers' implementation that can be toggled in- > place through alternatives doesn't hinder you from proving that the competing > implementation is better (faster, less systemd, etc); there are various ways > to do this; dpkg-divert, another non-"systemd-*" parent alternative, or > others. If /usr/bin/opensysusers-sysusers is really that good, have you tried > talking to maintainers using /bin/systemd-sysusers to see if they would like > to swap to it? It's not like having two competing implementations causes much > harm here. /usr/bin/systemd-* is clearly implementation-specific. Now, if we are to allow alternative implementations of /usr/bin/systemd-brewmycoffee, we should first push to an alternative /usr/bin/brewmycoffee, get the systemd maintainers to "subscribe" to it using our great alternatives system, and provide our /usr/bin/open-brewmycoffee. And I think that now, that not so many packages have yet adopted systemd-derived facilities, is a great time to set this as a good practice. signature.asc Description: PGP signature
Bug#947847: please install systemd-sysusers using update-alternatives
Thomas Goirand dijo [Wed, Jan 29, 2020 at 04:07:21PM +0100]: > This reasoning can make sense, if we agree that we should use something > else than /bin/systemd-sysusers and standardize on something else like > /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is > *the* way to do things, and using /bin/systemd-sysusers becomes a bug of > severity "serious" (policy violation). Yes for the general case, no for specifics. I mean - We should encourage people to use /bin/sysusers. Now, if systemd-sysusers grows a piece of functionality that open-sysusers is not willing to adopt (or vice versa), following past examples, I believe a package set to predepend on systemd-sysusers should be able to call /bin/systemd-sysusers — And a package set to predepend on open-sysusers can do likewise.
Bug#947847: please install systemd-sysusers using update-alternatives
On Wed, Jan 29, 2020 at 05:06:31PM +0100, Svante Signell wrote: > * E) systemd is not available on non-Linux - You don't need an alternative for something that does not exist. - Have you ever tried to build those parts of the systemd package on your favorite glibc non-Linux? Bastian -- There's another way to survive. Mutual trust -- and help. -- Kirk, "Day of the Dove", stardate unknown
Bug#947847: please install systemd-sysusers using update-alternatives
On Wed, 2020-01-29 at 16:49 +0100, Didier 'OdyX' Raboud wrote: > We'd first have to agree that an alternative is actually _needed_. > And so far, > the only arguments I have read in favour of providing alternatives to > /bin/systemd-sysusers are: > * A) it is shipped in the systemd binary package; > * B) Having competing implementations is important; > * C) it comes from the systemd project; > * D) it has a systemd-* name; * E) systemd is not available on non-Linux
Bug#947847: please install systemd-sysusers using update-alternatives
Le mercredi, 29 janvier 2020, 16.07:21 h CET Thomas Goirand a écrit : > This reasoning can make sense, if we agree that we should use something > else than /bin/systemd-sysusers and standardize on something else like > /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is > *the* way to do things, and using /bin/systemd-sysusers becomes a bug of > severity "serious" (policy violation). We'd first have to agree that an alternative is actually _needed_. And so far, the only arguments I have read in favour of providing alternatives to /bin/systemd-sysusers are: * A) it is shipped in the systemd binary package; * B) Having competing implementations is important; * C) it comes from the systemd project; * D) it has a systemd-* name; Out of these, A is the most convincing, B is mildly so; C & D are absolutely irrelevant IMHO. If you're concerned by A, the request becomes: > Please ship systemd-sysusers in a separate package for finer granularity and > smaller installation size for non-systemd systems If you're concerned by B, I don't think you need anything from systemd; just convince enough maintainers that a non-systemd implementation is important, and get them to change their scripts and dependencies to opensysusers. If you really want a single sysusers implementation per system (what's the argument there?), then go the /usr/bin/sysusers alternatives' route, and convince maintainers to move to that virtual package. -- OdyX signature.asc Description: This is a digitally signed message part.
Bug#947847: please install systemd-sysusers using update-alternatives
Le mercredi, 29 janvier 2020, 12.41:52 h CET Thomas Goirand a écrit :
> I'm replying to you, but it goes also for Phillip Kern too, which had a
> similar answer.
Only words, I know, but let's try to answer technical points, not address
people. "Talk to the space, not to individuals"
> My idea is to have a single entry point for programs to call the
> sysusers binary. If we collectively decide that it's going to be called
> /bin/foo, then by all means, let's do that. But I don't think it's
> reasonable to say it's going to be called /bin/systemd-bar, and nobody
> can take over this path. This is the wrong answer to the problem.
Software installed as /bin/systemd-* , created within the systemd project, to
fulfill systemd's view of the world, takes a reasonable hit on the binaries'
namespace: "systemd-*". Really, we should be thankful that the systemd project
actually started using /bin/systemd-sysusers and not just /bin/sysusers. To
extend on this, I think it's obvious that what the "systemd-sysusers" binary
name _says_ really is "this is a systemd-specific utility".
I'm of the opinion that noone should be allowed to take over this
/usr/bin/systemd-sysusers path, indeed. Much like I don't think anyone should
be allowed to provide an alternative to /usr/sbin/cupsd.
Let's see if I understand what you want correctly; you want Debian to allow
replacing systemd-specific software with alternatives, right? I'm sorry, but
this does not make any sense to me: /bin/systemd-sysusers _is_ systemd-
specific, and is used as such by systemd. If usages of it have appeared
outside of the systemd repository, I think it's fair to say (because of the
binary's name) that they were knowingly using a systemd-specific piece of
software (and hence, have correctly added a "{Pre-,}Depends: systemd".
Note that I'm not saying that /bin/systemd-sysusers _cannot_ be used without
systemd, or on a host booted with a different init system; I'm only saying
that usages of systemd-sysusers must have appeared with full knowledge of
using the systemd-sysusers binary from the systemd project.
> So I am in the opinion that "as long as it's properly hooked in the
> packaging system and boot sequence" simply doesn't work in this case, as
> systemd-sysusers could be called from virtually anywhere.
That's exactly the point: if it's so good that it has become used in many
places, changing the binary behind the scenes is clearly premature at this
point.
If I reformulate what it seems to me you're asking, it comes accross to me as
"/bin/systemd-sysusers comes from systemd and it should be possible to have a
system without systemd installed, therefore please force the systemd
maintainers to allow hosts to have a non-systemd /bin/systemd-sysusers".
My answer to this is that /bin/systemd-sysusers _is_ a systemd interface, with
a systemd-* name and I don't think it's reasonable to ask (or force) the
systemd maintainers to allow "their" interface to be implemented by other
software projects. Afterall, they came with the idea first, in their
namespace.
That said, taking a step back and looking at the larger picture, if what you
wish is a Debian in which one can pick their preferred sysusers'
implementation, what about discussing the pertinence of a "parent"
/bin/sysusers; with alternatives' setup there? (I wouldn't be surprised if the
systemd maintainers agreed to register /bin/systemd-sysusers as alternative to
/bin/sysusers).
With this in place, you could go to maintainers who _have_ already used
/bin/systemd-sysusers to try convince them to use the /bin/sysusers "standard"
interface instead. We have this for 'httpd', 'default-mta', what about having
a virtual 'sysusers' ?
All-in-all, I think the question you're asking is misguided: it's not because
we technically _can_ allow any /bin/systemd-* to be provided by another
implementation, that we should (actually, I think we should clearly _not_).
But not having a /bin/systemd-sysusers' implementation that can be toggled in-
place through alternatives doesn't hinder you from proving that the competing
implementation is better (faster, less systemd, etc); there are various ways
to do this; dpkg-divert, another non-"systemd-*" parent alternative, or
others. If /usr/bin/opensysusers-sysusers is really that good, have you tried
talking to maintainers using /bin/systemd-sysusers to see if they would like
to swap to it? It's not like having two competing implementations causes much
harm here.
Cheers,
OdyX
signature.asc
Description: This is a digitally signed message part.
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 1:50 PM, Raphael Hertzog wrote: > On Wed, 29 Jan 2020, Thomas Goirand wrote: >> echo 'u radvd - "radvd daemon"' | \ >>systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf > > Does opensysusers support this use case? Yes it does. > There's no need to predict the future, you must analyze the > current situation and go forward from there. Of course we are planning for the future. Let's say an important feature appears to be needed (this is just a point or argumentation at this time, please everyone: don't add unnecessary FUD), then of course, it's always possible to fill the gap and implement the missing feature. The clear goal is for opensysusers to become a full replacement of the systemd implementation. > As for the > service creating users during boot, you can provide a debconf > question giving the option to the user to install an override > of systemd-sysusers.service which actually calls opensysusers. The intend is for opensysusers to be a full replacement, I don't see why we should bother users with some annoying debconf prompt that they probably wont be able to understand without a an extensive knowledge of the situation. > And when we get to the point where the lack of systemd-sysuvers is a > problem, we can always patch programs to use /bin/create-system-users > instead of systemd-sysusers. I'm unsure what your above proposal is, so let's expand a little bit. Sorry if it appears I'm distorting your words (that's not the intent). This reasoning can make sense, if we agree that we should use something else than /bin/systemd-sysusers and standardize on something else like /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is *the* way to do things, and using /bin/systemd-sysusers becomes a bug of severity "serious" (policy violation). However, imposing everyone (for current or future use of sysusers) to handle a specific case for opensysusers is IMO *not* the way to go. And this is the very point of this bug entry. Cheers, Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
On Wed, 29 Jan 2020, Thomas Goirand wrote: > echo 'u radvd - "radvd daemon"' | \ >systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf Does opensysusers support this use case? If not, you just provided a good reason why it's not a good idea to use an alternative for systemd-sysusers. > My idea is to have a single entry point for programs to call the > sysusers binary. If we collectively decide that it's going to be called > /bin/foo, then by all means, let's do that. But I don't think it's > reasonable to say it's going to be called /bin/systemd-bar, and nobody > can take over this path. This is the wrong answer to the problem. I do believe it's not a good idea to reuse a systemd binary name for a generic API, even if that API is a subset of what's provided by systemd-sysusers. > I do agree that the data file is the interface, but can you predict > *ALL* the cases where /bin/systemd-sysusers is called? As much as I > understand, it could be called by: > - something debhelper adds to postinst > - something the maintainer adds manually to postinst > - the init system itself There's no need to predict the future, you must analyze the current situation and go forward from there. AFAIK, we don't have anything at the debhelper level yet and we can define that debhelper will call your new /bin/foo^Wcreate-system-users. As for the service creating users during boot, you can provide a debconf question giving the option to the user to install an override of systemd-sysusers.service which actually calls opensysusers. The question would not be shown by default and would default to not override systemd-sysusers. It would also not be shown if systemd is not used. > And more disturbingly, it could be called by any program that just wants > to add a user the same way one would just call useradd or adduser. The > man page for systemd-sysusers even gives a very clear example: Given that both programs are doing the same thing based on the same input, I don't see any problem in that. We have dependencies to ensure that programs are available. And when we get to the point where the lack of systemd-sysuvers is a problem, we can always patch programs to use /bin/create-system-users instead of systemd-sysusers. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 11:34 AM, Raphael Hertzog wrote: > On Tue, 28 Jan 2020, Thomas Goirand wrote: >> This is exactly what should be avoided. It's perfectly fine to try to >> use opensysusers with systemd if one wants. In fact, that's exactly the >> best way we could do to be able to test it. Also, dpkg-divert is really >> ugly, and something you use as the last resort, when all other options >> have been exhausted. > > It's not that ugly if you consider that you are in an experimental phase > where you want to test opensysusers. > > Also you seem to imply that the common interface is the systemd-sysusers > binary. I don't think that this is necessarily the case. The common > interface is the file format. The name of the program creating the users > is not important as long as it's properly hooked in the packaging system > and boot sequence. Hi Raphael, I'm replying to you, but it goes also for Phillip Kern too, which had a similar answer. My idea is to have a single entry point for programs to call the sysusers binary. If we collectively decide that it's going to be called /bin/foo, then by all means, let's do that. But I don't think it's reasonable to say it's going to be called /bin/systemd-bar, and nobody can take over this path. This is the wrong answer to the problem. I do agree that the data file is the interface, but can you predict *ALL* the cases where /bin/systemd-sysusers is called? As much as I understand, it could be called by: - something debhelper adds to postinst - something the maintainer adds manually to postinst - the init system itself And more disturbingly, it could be called by any program that just wants to add a user the same way one would just call useradd or adduser. The man page for systemd-sysusers even gives a very clear example: echo 'u radvd - "radvd daemon"' | \ systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf which clearly, looks like something someone would write in a shell script, manually calling /bin/systemd-sysusers, from anywhere, maybe even from a running program / daemon (I haven't seen any designed limitation, have you?). So I am in the opinion that "as long as it's properly hooked in the packaging system and boot sequence" simply doesn't work in this case, as systemd-sysusers could be called from virtually anywhere. As for the use of dpkg-divert, as you wrote above, it's ok for experimentation, but I do think it's making a disservice to our users to use that as the proper interface to implement. The update-alternatives has the very nice advantage that it clearly shows the current status of the system, and that it can be very easily tweaked, by hand or by some kind of automation. It's also super easy to go from one state of the system to another, compared to reinstalling / uninstalling a package. Cheers, Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
On Tue, 28 Jan 2020, Thomas Goirand wrote: > This is exactly what should be avoided. It's perfectly fine to try to > use opensysusers with systemd if one wants. In fact, that's exactly the > best way we could do to be able to test it. Also, dpkg-divert is really > ugly, and something you use as the last resort, when all other options > have been exhausted. It's not that ugly if you consider that you are in an experimental phase where you want to test opensysusers. Also you seem to imply that the common interface is the systemd-sysusers binary. I don't think that this is necessarily the case. The common interface is the file format. The name of the program creating the users is not important as long as it's properly hooked in the packaging system and boot sequence. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/28/2020 1:33 PM, Thomas Goirand wrote: >> It'd need to be a script that the systemd maintainers feel reasonably >> confident will always run systemd's implementation when systemd is >> running, to avoid the mixed implementations issue. > > Not at all. Systemd maintainers have no say if someone wishes to > implement things in another way, the same way there's gawk and mawk, > implementing the same thing. If we don't allow such things, then really, > Debian is doomed. The interface in question here is "awk". So if the interface would be a hypothetical "update-sysusers", then this could be shared with alternatives. I completely understand the view of the systemd maintainers that "systemd-sysusers" as a binary should be provided by their package rather than an alternative. >> Strikes me as there is a possible solution, though: have opensysusers >> dpkg-divert it and put a shell script in its place that checks which >> init system is running, and exec's the right sysusers based on that. > > This is exactly what should be avoided. It's perfectly fine to try to > use opensysusers with systemd if one wants. In fact, that's exactly the > best way we could do to be able to test it. Also, dpkg-divert is really > ugly, and something you use as the last resort, when all other options > have been exhausted. If the problem here is that everything embeds a call to systemd-sysusers directly and you want to provide a different intermediate interface eventually then diverting it as a workaround in the meantime seems sound to me, no? So far I see you present a single option rather than trying to negotiate within the option space. Good escalations are not "Moreover, I don't see why /usr/bin/systemd-sysusers would be any different from let's say /usr/bin/awk." but trying to present the two opposing viewpoints and potential solutions to them. Kind regards Philipp Kern
Bug#947847: please install systemd-sysusers using update-alternatives
Anthony DeRobertis
> It's different than awk because the decision the admin is making
> ("which init system do I want to run"?) isn't done through
> alternatives. So you can't use the alternatives system to coordinate
> swapping all the different bits together.
You are mixing things here. We are *not* talking about init systems, but
about sysusers, which can be used with any init systems.
> It seems retty reasonable to me that the systemd maintainers don't
> want to support systems which are running arbitrary combinations of
> systemd with alternatives to some parts.
Absolutely nobody is asking them to do that. I'm just asking for a
solution to easily replace /bin/systemd-sysusers. There are 2 solutions,
one is to have /bin/systemd-sysusers packaged separately, though this
would probably be micro-packaging, which I'm not a fan of. The other
solution is to use update-alternatives. I'm fine with both solution, I
just don't think it's fine to say "get away, my implementation is
better", and leave no reasonable solution to install something else.
> Strikes me as there is a possible solution, though: have opensysusers
> dpkg-divert it and put a shell script in its place that checks which
> init system is running, and exec's the right sysusers based on that.
This is exactly what should be avoided. It's perfectly fine to try to
use opensysusers with systemd if one wants. In fact, that's exactly the
best way we could do to be able to test it. Also, dpkg-divert is really
ugly, and something you use as the last resort, when all other options
have been exhausted.
> This wouldn't affect systemd-only machines (as opensysusers would not
> be installed at all), and would do the right thing if someone has
> installed two init systems to, e.g., consider switching.
Again, you are mixing things (ie: what type of init system and
re-implementation of an independent component of systemd). We should be
able to allow to run opensysusers if systemd is running (exactly, why
not?). This is desirable, at least for testing. It would also be
desirable to use systemd-sysusers with other init system if one wants
(also: why not?).
> It'd need to be a script that the systemd maintainers feel reasonably
> confident will always run systemd's implementation when systemd is
> running, to avoid the mixed implementations issue.
Not at all. Systemd maintainers have no say if someone wishes to
implement things in another way, the same way there's gawk and mawk,
implementing the same thing. If we don't allow such things, then really,
Debian is doomed.
I am not buying into the "we will have wrong bug reports" argument. We
constantly get many types of wrong reports in the BTS. We just shall do
sensible bug triaging in a correct way, that's it.
Cheers,
Thomas Goirand (zigo)
P.S: Note that this bug also concerns systemd-tmpfiles, the very exact
same way, though I believe one single bug is enough to address both
cases which are similar.
Bug#947847: please install systemd-sysusers using update-alternatives
Am 27.01.20 um 14:19 schrieb Michael Biebl: > Am 27.01.20 um 11:18 schrieb Thomas Goirand: > >> It is my view that what you're proposing would be a lot more work for on >> valid reason. > > opensysusers as implementation will always lag behind systemd-sysusers > and/or be incomplete, it might even be incompatible. > This has the potential to negatively effect a systemd installation > leading to a less robust system. Those issues will likely be hard to > diagnose where we as maintainers have to spend time which would be > better spent elsewhere. > And all that for what? I don't see a compelling use case why swapping > out the native reference implementation and running a combination which > is untested (and unsupported by systemd upstream) would be a good idea. I'm not subscribed to this bug report, so if the CTTE want's further feedback on this issue from my side, please CC me. Michael signature.asc Description: OpenPGP digital signature
Bug#947847: [Fwd: Re: Bug#947847: please install systemd-sysusers using update-alternatives]
--- Begin Message --- On Mon, 2020-01-27 at 11:01 -0500, Anthony DeRobertis wrote: > > Strikes me as there is a possible solution, though: have opensysusers > dpkg-divert it and put a shell script in its place that checks which > init system is running, and exec's the right sysusers based on that. It is as simple as: if ps -p1|grep -q "systemd"; then else fi > This wouldn't affect systemd-only machines (as opensysusers would not be > installed at all), and would do the right thing if someone has installed > two init systems to, e.g., consider switching. It'd need to be a script > that the systemd maintainers feel reasonably confident will always run > systemd's implementation when systemd is running, to avoid the mixed > implementations issue. --- End Message ---
Bug#947847: please install systemd-sysusers using update-alternatives
It's different than awk because the decision the admin is making ("which
init system do I want to run"?) isn't done through alternatives. So you
can't use the alternatives system to coordinate swapping all the
different bits together.
It seems retty reasonable to me that the systemd maintainers don't want
to support systems which are running arbitrary combinations of systemd
with alternatives to some parts. And that a package with a Depends on a
particular systemd version should be able to depend on features from
that version; alternatives would allow an old version of opensysusers to
be used instead (unless systemd kept adding conflicts against
opensysusers whenever they add a new feature, something I doubt anyone
would be happy with).
Strikes me as there is a possible solution, though: have opensysusers
dpkg-divert it and put a shell script in its place that checks which
init system is running, and exec's the right sysusers based on that.
This wouldn't affect systemd-only machines (as opensysusers would not be
installed at all), and would do the right thing if someone has installed
two init systems to, e.g., consider switching. It'd need to be a script
that the systemd maintainers feel reasonably confident will always run
systemd's implementation when systemd is running, to avoid the mixed
implementations issue.
(Of course, there is the problem with temporarily having no file
there... but I suspect that could be documented around as the lesser of
evils. Especially if done with --no-rename, so it'd be a very short time.)
Bug#947847: please install systemd-sysusers using update-alternatives
Am 27.01.20 um 11:18 schrieb Thomas Goirand: > It is my view that what you're proposing would be a lot more work for on > valid reason. opensysusers as implementation will always lag behind systemd-sysusers and/or be incomplete, it might even be incompatible. This has the potential to negatively effect a systemd installation leading to a less robust system. Those issues will likely be hard to diagnose where we as maintainers have to spend time which would be better spent elsewhere. And all that for what? I don't see a compelling use case why swapping out the native reference implementation and running a combination which is untested (and unsupported by systemd upstream) would be a good idea. Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/25/20 5:05 PM, Michael Biebl wrote: > Control: tags -1 + wontfix > > Hi Thomas > > On Tue, 31 Dec 2019 17:29:29 +0100 Thomas Goirand wrote: >> Package: systemd >> Version: 244-3 >> Severity: important >> >> Hi, >> >> As I'm packaging opensysusers (see ITP: #947846), I would like my >> package to also provide /bin/systemd-sysusers. Please install this >> binary on another location, so that both systemd and opensysusers can >> implement it. I am very much fine to have systemd have the priority over >> opensysusers if you believe it should (I'm open to discussion about >> priorities). > > Thanks for your interest in systemd-sysusers. > After thinking more about this, I don't consider renaming > systemd-sysusers and installing it via alternatives as a good idea. > > When systemd is installed and used, we definitely want to use its own > implementation. > > My recommendation would be to install the opensysusers implementation > under a different binary name. > > Alternative init systems can then decide to support sysusers by calling > that opensysusers binary during boot. > debhelper, should it get sysusers support, should generate code which > calls the correct binary depending on the current circumstances. > > Regards, > Michael > > > Hi Michael, It is my view that what you're proposing would be a lot more work for on valid reason. I'm therefore re-assigning the bug to the tech-ctte, asking them to decided instead. It is my view that using update-alternatives is *very* easy to implement, so that we can share the /usr/bin/systemd-sysuser location. Besides the fact that, with the way you're suggesting, we'd need to fix debhelper (which I don't think is reasonable, as it wont be the only place to handle multiple cases, I'm foreseeing...), there's also the concern that you don't seem to agree that it'd be ok for one to use opensysuser instead of the systemd implementation if systemd is running. I do not agree with this, and I believe it is up to the users to decide what to do, even if we, as an operating system, must provide sensible defaults (which also can be discussed, but that's not the point of this bug report). Moreover, I don't see why /usr/bin/systemd-sysusers would be any different from let's say /usr/bin/awk. The update-alternatives system is there exactly to handle the case we're facing today. So, tech-ctte, please decide. Cheers, Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
Package: systemd Version: 244-3 Severity: important Hi, As I'm packaging opensysusers (see ITP: #947846), I would like my package to also provide /bin/systemd-sysusers. Please install this binary on another location, so that both systemd and opensysusers can implement it. I am very much fine to have systemd have the priority over opensysusers if you believe it should (I'm open to discussion about priorities). Cheers, Thomas Goirand (zigo)
