Hello, On May 24 16:49 Jan Engelhardt wrote (excerpt):

About *all* of our packages also depend on the presence of the "filesystem" package, yet there is no rpm require tag for that anywhere. Therefore, 980389 suggested, in a note bene, to preinstall systemd through these same means as aaa_base/filesystem rather than through Requires(pre).

I do fully agree and even more: In the end what I would like to have is that the package that provides the actual software for a service provides only the plain software (e.g. /usr/sbin/foo) but all what belongs to using that plain software as a service should be provided separated from the plain software. I am thinking about a separated (sub)-package "foo-systemd" that contains the systemd pieces for the "foo" software (usually systemd unit files and systemd RPM scriptlets and the %{?systemd_requires} RPM requirements). Without systemd or without "foo-systemd" it is up to the admin how to launch /usr/sbin/foo when it should be used as a service. I think "foo-systemd" must have a RPM requirement for "foo" but "foo" must not have a RPM requirement for "foo-systemd" when the plain "foo" software can run without systemd. In "foo" a RPM recommends for "foo-systemd" could be correct or (perhaps better) a "Supplements: foo" in "foo-systemd". Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, On May 25 15:20 Andrei Borzenkov wrote (excerpt):

On Wed, May 25, 2016 at 3:13 PM, Johannes Meixner wrote:

...

I am thinking about a separated (sub)-package "foo-systemd" that contains the systemd pieces for the "foo" software (usually systemd unit files and systemd RPM scriptlets and the %{?systemd_requires} RPM requirements).

... what harm single file installed on your system causes you? If you do not want to use it, do not use it.

The systemd unit file is only one of three items. I don't care about some useless installed files. But I wonder about the systemd RPM scriptlets and the %{?systemd_requires} RPM requirements in the "foo" main-package. Don't they harm when no systemd is there? Of course when systemd is always there (e.g. via aaa_base) the whole issue is pointless. I thought the issue is about when no systemd is there? Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

25.05.2016 21:23, Thorsten Kukuk пишет:

On Wed, May 25, Johannes Meixner wrote:

...

I am thinking about a separated (sub)-package "foo-systemd" that contains the systemd pieces for the "foo" software (usually systemd unit files and systemd RPM scriptlets and the %{?systemd_requires} RPM requirements).

Without systemd or without "foo-systemd" it is up to the admin how to launch /usr/sbin/foo when it should be used as a service.

I think "foo-systemd" must have a RPM requirement for "foo" but "foo" must not have a RPM requirement for "foo-systemd" when the plain "foo" software can run without systemd.

In "foo" a RPM recommends for "foo-systemd" could be correct or (perhaps better) a "Supplements: foo" in "foo-systemd".

This would become a nightmare. A lot of people would only get the main package installed but not the systemd start scripts. In a lot of cases it doesn't make sense to evaluate recommends, so we disable them. Else you would get installed all the packages again you deselected before. And you don't want to do the deselect step with every update.

I agree. This is unmanageable unless we can express dependency "if systemd is installed then requires foo-systemd". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 2016-05-26 05:31, Andrei Borzenkov wrote:

...

...

I think "foo-systemd" must have a RPM requirement for "foo" but "foo" must not have a RPM requirement for "foo-systemd" when the plain "foo" software can run without systemd.

In "foo" a RPM recommends for "foo-systemd" could be correct or (perhaps better) a "Supplements: foo" in "foo-systemd".

This would become a nightmare. A lot of people would only get the main package installed but not the systemd start scripts. In a lot of cases it doesn't make sense to evaluate recommends, so we disable them. Else you would get installed all the packages again you deselected before. And you don't want to do the deselect step with every update.

I agree. This is unmanageable unless we can express dependency "if systemd is installed then requires foo-systemd".

%package systemd Supplements: packageand(%name:systemd) But of course, if it is in any way approachable without hundreds of extra little packages, that'd be great(er). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 2016-05-26 05:33, Andrei Borzenkov wrote:

...

But I wonder about the systemd RPM scriptlets and the %{?systemd_requires} RPM requirements in the "foo" main-package.

Don't they harm when no systemd is there?

The scriptlet tests for existence of systemctl and tmpfiles first, and do nothing if they are not there. Which is ok as long as ( systemd is *not* in the to-be-installed package set || is going to be installed before package xxx ). Unfortunately, rpm's "Requires(pre)" is, to use systemd's own terms, both a "Wants" (request for existence) and a "Before" (request for installation ordering), and is the figurative bite in the butt. Maybe zypper devs can give us support for "Supplements: order_after(systemd)", similar to the fancy packageand() stuff.

Scriptlets need only systemctl. In early days of systemd this was solved by providing systemctl as separate package, so packages could require it without requiring systemd itself.

I like the idea. (I think it's possible to pull it off.) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 2016-05-24 at 16:49 +0200, Jan Engelhardt wrote:

When using `zypper -R /blah` to install into an empty or near-empty  directory for the sake of erecting a chroot and/or running a Linux  container, extra packages like systemd get installed even though they  are not required for normal operation. You can in fact rpm -e it again  after the zypper run. So let's not install systemd in the first place.  All of that can be read at https://bugzilla.opensuse.org/980389 .

There are now some people who terribly insist that they must add  %systemd_reqiures to every .service file shipping package. Like https://bugzilla.opensuse.org/976922 . So now we at an impassé.

About *all* of our packages also depend on the presence of the  "filesystem" package, yet there is no rpm require tag for that anywhere.  Therefore, 980389 suggested, in a note bene, to preinstall systemd  through these same means as aaa_base/filesystem rather than through  Requires(pre).

Maybe it would be beneficial to start with the actual problem statements in order to decide what the correct / best route is 1) Users want that their system works reliable, without room for accident. That's where those scripts come in handy to do 'the right thing' with the services. For them to work reliably %{systemd_requires} is mandatory - as this is the only way to ensure thay systemctl is actually present 2) users of contains wish to not have systemd inside the container. Keeping the container small is a benefit, additionally, a service inside the container is usually not managed by systemd. So this serves no purpose there.

From there, I think it's best to discuss if we can realistically accomodate both use-cases or, should this not be the case, which one we rate more important.

Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org