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
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-dive
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 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 mu
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 i
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* wa
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
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'
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 t
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
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
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_).
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 thi
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,
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
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 sho
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 modi
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 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 "Depe
20 matches
Mail list logo
