Mailinglist Archive: opensuse-packaging (118 mails)

< Previous Next >
Re: [opensuse-packaging] systemd presets vs. package install order

thanks for all the responses!

Am Montag, 15. Juni 2015 schrieb Dimstar / Dominique Leuenberger:
On Mon, 2015-06-15 at 12:32 +0200, Stephan Kulow wrote:
On 15.06.2015 12:22, Dimstar / Dominique Leuenberger wrote:

What about something like this in apparmor's post script:

if [ "$1" = "1" ]; then # This is a fresh install, not an
systemctl preset apparmor.service # Set the service
enable/disable as per distribution preset

This should be ess surprising in all cases, and if the preset ever
changes, this would not even need to be changed, and still do the
right thing on a new package install

For the records: The AppArmor package has to cover two usecases when it
comes to preset (= enable) the service file:
a) fresh install
b) update from older version (from openSUSE <= 13.2), which didn't have
a service file

%service_add_pre apparmor.service (in %pre) and %service_add_post
apparmor.service (in %post) are expected to cover both cases.
Just to avoid the question: yes, those macro calls are in apparmor.spec.

Hmm, I just wanted to say that %systemd_requires is also there and it
actually is - but at a slightly wrong place, which means it won't be
used for the apparmor-parser package :-/ (Argh, I should really double-
and triple-check SRs, even (or especially?) if they come from systemd
experts :-/ ) A package with %systemd_requires at the right place is
in security:apparmor (and on its way to tumbleweed, SR 312168).

An interesting question remains - %systemd_requires adds _unversioned_
Requires(post) etc. - how can I be sure that systemd and the preset
package get updated before apparmor-parser gets updated?
Unfortunately this can't be tested easily - I'd have to install a fresh
tumbleweed (easy one - on a fresh install, even unversioned dependencies
work) or even 13.2 and then update to tumbleweed :-/ (Did I miss an
easy way to test?)

If we do this, what's the purpose of the
systemd-presets-branding-openSUSE ? Shouldn't apparmor require it
directly or indirectly?

The idea wouldn't work anyway - as apparmor is installed prior to the
preset package and thus can't read the default.

Exactly this is the problem - and in this case the "*: disabled" default
will be used.

I'm seriously thinking about adding something like
grep ' apparmor.service' /usr/lib/systemd/system-preset/*.preset >/dev/null
|| systemctl enable apparmor.service
to make sure we get the expected result if the preset package wasn't
updated yet, while honoring the preset if it is there. This doesn't cover
all cases (especially tumbleweed -> newer tumbleweed [1]), but at least
updates from <= 13.2.

If someone has an idea how I can fix this for everybody, please speak
up ;-)


Christian Boltz

[1] for a moment, I thought about checking the timestamp of
/var/lib/systemd/migrated/apparmor (and ignoring it if it's older
than the guaranteed-to-work %post script), but I'm not sure if this
is the best idea.
<jjohansen> I just need to stop responding to cboltz
<cboltz> no, but you should come up with things I don't notice ;-)
<jjohansen> something you don't notice? Isn't that asking a bit much :)
<cboltz> no, that's called "high quality code" or at least "high quality
well-hidden bug" *g,d&r*
* jjohansen fails to believe there is such a thing as a well-hidden bug
for cboltz
[from #apparmor]

To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups