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
(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
>
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
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
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,
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:
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
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-
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
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}
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
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
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
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,
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
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_).
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
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
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
>
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
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
--
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
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*
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
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
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.
>
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,
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
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
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
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
--- 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
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
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
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: 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
36 matches
Mail list logo
