Le 05/12/2014 16:42, Lennart Poettering a écrit :
On Fri, 05.12.14 16:02, Didier Roche (didro...@ubuntu.com) wrote:
This would also only fix the newly installed case, not the upgrade with
new distro defaults or various purge vs remove ones. That's why I think some
kind of previous state db
On Sun, 07.12.14 09:39, Martin Pitt (martin.p...@ubuntu.com) wrote:
Hello all,
sorry for the late response.
Andrei Borzenkov [2014-12-05 10:58 +0300]:
That's not how I actually understood it. enable/disable still applies
only to units with [Install] section as it is now. Just that
On Fri, Dec 05, 2014 at 05:55:39PM +0200, Uoti Urpala wrote:
Just leaving the symlinks would not give good behavior even in the case
where the admin wants to keep the old target: temporary disable + then
re-enable would now change the target. Perhaps the recommended way to
change targets in
Hello all,
sorry for the late response.
Andrei Borzenkov [2014-12-05 10:58 +0300]:
That's not how I actually understood it. enable/disable still applies
only to units with [Install] section as it is now. Just that
Correct. I don't see any need to change the behaviour of static units,
and I
Lennart Poettering [2014-12-05 14:52 +0100]:
To be honest I find the entire stuff with ENABLED=true/false really
questionnable, I think it would be agreat step ahead to get rid of
it. (But then again, I cannot make Debian's decisions there...)
Indeed it is. It has never really been necessary,
В Sun, 7 Dec 2014 09:39:50 +0200
Martin Pitt martin.p...@ubuntu.com пишет:
Hello all,
sorry for the late response.
Andrei Borzenkov [2014-12-05 10:58 +0300]:
That's not how I actually understood it. enable/disable still applies
only to units with [Install] section as it is now. Just
Hello,
Andrei Borzenkov [2014-12-07 14:39 +0300]:
Indeed the part after the OR is the only change that I propose. I. e.
- systemctl enable: If /usr/.../wants/foo.service exists, remove the
/dev/null symlink in /etc/.../wants/foo.service if it exists (if
not, it's already
On Sun, Dec 7, 2014 at 11:27 PM, Martin Pitt martin.p...@ubuntu.com wrote:
Hello,
Andrei Borzenkov [2014-12-07 14:39 +0300]:
Indeed the part after the OR is the only change that I propose. I. e.
- systemctl enable: If /usr/.../wants/foo.service exists, remove the
/dev/null symlink
Le 05/12/2014 02:13, Lennart Poettering a écrit :
On Tue, 02.12.14 12:50, Didier Roche (didro...@ubuntu.com) wrote:
Just to sum up other branches of this thread: we are trying to avoid having
systemctl calls in debian/ubuntu postinst (or duplicated manual symlinks
logic as we currently have).
On Fri, 05.12.14 11:06, Didier Roche (didro...@ubuntu.com) wrote:
It seems maintaining this list in sync for all flavors would be a growing
pain (this is a positive effect of the disable by default: you don't have to
maintain such a list), or do you think we can come with something
better?
Lennart Poettering wrote on 05/12/14 13:52:
Only preinst can (getting the install or upgrade argument), not
postinst
(getting configure in both case). And we need to run the preset/enable in
postinst (meaning: after unpacking).
This sounds quite a limitation. Maybe you can keep a couple
Le 05/12/2014 14:52, Lennart Poettering a écrit :
On Fri, 05.12.14 11:06, Didier Roche (didro...@ubuntu.com) wrote:
It seems maintaining this list in sync for all flavors would be a growing
pain (this is a positive effect of the disable by default: you don't have to
maintain such a list), or
On Fri, 05.12.14 16:02, Didier Roche (didro...@ubuntu.com) wrote:
Whenever the preset db is queried we'll no longer just return the
verdict boolean, but also a numeric overall line number, of the line
we found the verdict on. Then, when preset-all is invoked, we
determine all the operations
On Fri, 2014-12-05 at 02:39 +0100, Lennart Poettering wrote:
On Tue, 02.12.14 20:02, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
On Tue, 2014-12-02 at 01:51 +0100, Lennart Poettering wrote:
On Tue, 18.11.14 16:09, Michael Biebl (mbi...@gmail.com) wrote:
WantedBy=multi-user.target
On Fri, 05.12.14 10:58, Andrei Borzenkov (arvidj...@gmail.com) wrote:
That's not how I actually understood it. enable/disable still applies
only to units with [Install] section as it is now. Just that
systemctl disable
means that if there are links in /usr/lib, they are masked in /etc.
On Tue, 02.12.14 12:50, Didier Roche (didro...@ubuntu.com) wrote:
Just to sum up other branches of this thread: we are trying to avoid having
systemctl calls in debian/ubuntu postinst (or duplicated manual symlinks
logic as we currently have).
systemctl preset seems the cleanest path, but we
On Tue, 02.12.14 20:02, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
On Tue, 2014-12-02 at 01:51 +0100, Lennart Poettering wrote:
On Tue, 18.11.14 16:09, Michael Biebl (mbi...@gmail.com) wrote:
2014-11-18 15:59 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
For the avoidance of doubt,
В Fri, 5 Dec 2014 02:39:09 +0100
Lennart Poettering lenn...@poettering.net пишет:
On Tue, 02.12.14 20:02, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
On Tue, 2014-12-02 at 01:51 +0100, Lennart Poettering wrote:
On Tue, 18.11.14 16:09, Michael Biebl (mbi...@gmail.com) wrote:
Lennart Poettering wrote on 02/12/14 00:25:
On Tue, 18.11.14 14:40, Colin Guthrie (gm...@colin.guthr.ie) wrote:
Well the upstream blessed RPM way is to call %systemd_post macro in
your %post script, but (personally) I don't like this as it makes the
implementation very much embedded into the
Just to sum up other branches of this thread: we are trying to avoid
having systemctl calls in debian/ubuntu postinst (or duplicated manual
symlinks logic as we currently have).
systemctl preset seems the cleanest path, but we want to ensure corner
cases can be handled.
d/u policy is to
On Tue, 02.12.14 01:29, Lennart Poettering (lenn...@poettering.net) wrote:
On Tue, 18.11.14 14:10, Tom Gundersen (t...@jklm.no) wrote:
- We are mixing sys admin information and distro default choices in the
same
directories, and can't tell apart what is what.
That is true. Could
Didier Roche wrote on 02/12/14 11:50:
Just to sum up other branches of this thread: we are trying to avoid
having systemctl calls in debian/ubuntu postinst (or duplicated manual
symlinks logic as we currently have).
systemctl preset seems the cleanest path, but we want to ensure corner
cases
On Tue, 2014-12-02 at 01:51 +0100, Lennart Poettering wrote:
On Tue, 18.11.14 16:09, Michael Biebl (mbi...@gmail.com) wrote:
2014-11-18 15:59 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
For the avoidance of doubt, I believe that running systemctl preset
should only ever happen on
On Tue, 18.11.14 12:11, Didier Roche (didro...@ubuntu.com) wrote:
Fedora doesn't enable and start all units on package installation: there are
some preset files, based on flavors, which is basically the policy stating
which units to enable/disable by default. Some other units are always
On Tue, 18.11.14 13:01, Martin Pitt (martin.p...@ubuntu.com) wrote:
We can certainly ship a preset of enable * to reflect the policy
that in general services do get enabled by default. But this still
leaves some issues:
No need to ship enable *, btw. It's the implied default if no preset
file
On Tue, 18.11.14 14:40, Colin Guthrie (gm...@colin.guthr.ie) wrote:
Well the upstream blessed RPM way is to call %systemd_post macro in
your %post script, but (personally) I don't like this as it makes the
implementation very much embedded into the RPMs so changing the upstream
macro needs a
On Tue, 18.11.14 14:10, Tom Gundersen (t...@jklm.no) wrote:
- We are mixing sys admin information and distro default choices in the same
directories, and can't tell apart what is what.
That is true. Could we perhaps improve on systemctl by printing
enabled (preset)/disable (preset) for
On Tue, 18.11.14 14:37, Martin Pitt (martin.p...@ubuntu.com) wrote:
We now have:
enabeld - [Install] section and symlink in /etc/**/*.wants.d/
disabled - [Install] section and no symlink in /etc/**/*.wants.d/
static - no [Install] section and symlink in /usr/lib/**/*.wants.d/
masked -
On Tue, 18.11.14 16:09, Michael Biebl (mbi...@gmail.com) wrote:
2014-11-18 15:59 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
Didier Roche wrote on 18/11/14 13:58:
This would be maybe a nice way for the admin to know what's coming from
a distribution default or not. However, let's say I
On Fri, 28.11.14 11:15, Didier Roche (didro...@ubuntu.com) wrote:
The distribution comes preinstalled with one dm, enable * - enable it, have
the Alias=display-manager.service picking the right one.
However, let's say the user installed then another dm, what happens? Both
will be enabled if
Le 21/11/2014 12:08, Colin Guthrie a écrit :
Hello again!
Hey, trying to revive the topic :)
Didier Roche wrote on 18/11/14 15:40:
Le 18/11/2014 15:59, Colin Guthrie a écrit :
Hiya,
Hey,
Didier Roche wrote on 18/11/14 13:58:
This would be maybe a nice way for the admin to know what's
Hello again!
Didier Roche wrote on 18/11/14 15:40:
Le 18/11/2014 15:59, Colin Guthrie a écrit :
Hiya,
Hey,
Didier Roche wrote on 18/11/14 13:58:
This would be maybe a nice way for the admin to know what's coming from
a distribution default or not. However, let's say I want to ensure that
Andrei Borzenkov wrote on 19/11/14 17:49:
В Tue, 18 Nov 2014 16:22:18 +
Colin Guthrie gm...@colin.guthr.ie пишет:
Michael Biebl wrote on 18/11/14 15:55:
2014-11-18 16:30 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
Michael Biebl wrote on 18/11/14 15:09:
2014-11-18 15:59 GMT+01:00
В Tue, 18 Nov 2014 16:22:18 +
Colin Guthrie gm...@colin.guthr.ie пишет:
Michael Biebl wrote on 18/11/14 15:55:
2014-11-18 16:30 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
Michael Biebl wrote on 18/11/14 15:09:
2014-11-18 15:59 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
Didier
Fedora doesn't enable and start all units on package installation: there
are some preset files, based on flavors, which is basically the policy
stating which units to enable/disable by default. Some other units are
always enabled (unless masked), by using symlinks directly shipped with
the
Didier Roche wrote on 18/11/14 11:11:
Fedora doesn't enable and start all units on package installation: there
are some preset files, based on flavors, which is basically the policy
stating which units to enable/disable by default. Some other units are
always enabled (unless masked), by using
Hello Colin, all,
Colin Guthrie [2014-11-18 11:30 +]:
I believe that it is generally discouraged to use systemctl enable
indirectly or otherwise during postinst.
Right, I don't like this either, hence this discussion. :-) I don't
know whether Debian's current way of enabling units on
Hi Didier,
On Tue, Nov 18, 2014 at 12:11 PM, Didier Roche didro...@ubuntu.com wrote:
This has 3 drawbacks:
- Duplicate symlinks for the same targets between /etc and units enabled in
/usr/lib for units which are already enabled via /usr/lib, if the admin runs
enable
This I think should be
Hey Tom,
Tom Gundersen [2014-11-18 14:10 +0100]:
This I think should be considered a bug in the unit file. If a unit
has a /usr/lib symlink, then it is statically enabled (i.e.,
'enable'/'disable' has no effect), so it should not install symlinks
in /etc, and hence not have an [Install]
Hey Colin,
thanks for the discussion! Trimming heavily; as you said we should let
some other upstreams chime in too, I just have some followup
questions.
Colin Guthrie [2014-11-18 13:01 +]:
* I suppose even wich such a policy the post-installation script
still needs to call some
Le 18/11/2014 14:10, Tom Gundersen a écrit :
Hi Didier,
Thanks for your answer Tom and sharing your thoughts on this.
On Tue, Nov 18, 2014 at 12:11 PM, Didier Roche didro...@ubuntu.com wrote:
This has 3 drawbacks:
- Duplicate symlinks for the same targets between /etc and units enabled in
Hey Colin,
Colin Guthrie [2014-11-18 14:40 +]:
In Mageia we do something similar but we shell out to a script instead.
This allows us to replace the implementation without rebuilding all
packages.
Debian does the same, there's a deb-systemd-helper wrapper called in
the postinst scripts
On Tue, Nov 18, 2014 at 2:58 PM, Didier Roche didro...@ubuntu.com wrote:
This I think should be considered a bug in the unit file. If a unit
has a /usr/lib symlink, then it is statically enabled (i.e.,
'enable'/'disable' has no effect), so it should not install symlinks
in /etc, and hence not
Hiya,
Didier Roche wrote on 18/11/14 13:58:
This would be maybe a nice way for the admin to know what's coming from
a distribution default or not. However, let's say I want to ensure that
ssh will always be available on my server, I would (even if it's in my
server preset) then systemctl
2014-11-18 15:59 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
Didier Roche wrote on 18/11/14 13:58:
This would be maybe a nice way for the admin to know what's coming from
a distribution default or not. However, let's say I want to ensure that
ssh will always be available on my server, I
2014-11-18 15:40 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
Longer term, I want to move this to filetriggers. We have been using
filetriggers for a while via an RPM patch and it looks like some kind of
similar functionality will be (at long last) making it to upstream RPM
in the nearish
Le 18/11/2014 15:55, Tom Gundersen a écrit :
I get where you are coming from, but presets will give you the same
result, no?
Apart from what we discussed on this thread with Martin about the /etc
clutterness having distro-specific information and not only system ones,
right.
However, this is
Michael Biebl wrote on 18/11/14 15:09:
2014-11-18 15:59 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
Didier Roche wrote on 18/11/14 13:58:
This would be maybe a nice way for the admin to know what's coming from
a distribution default or not. However, let's say I want to ensure that
ssh will
Le 18/11/2014 15:59, Colin Guthrie a écrit :
Hiya,
Hey,
Didier Roche wrote on 18/11/14 13:58:
This would be maybe a nice way for the admin to know what's coming from
a distribution default or not. However, let's say I want to ensure that
ssh will always be available on my server, I would
2014-11-18 16:30 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
Michael Biebl wrote on 18/11/14 15:09:
2014-11-18 15:59 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
Didier Roche wrote on 18/11/14 13:58:
This would be maybe a nice way for the admin to know what's coming from
a distribution
2014-11-18 14:52 GMT+01:00 Martin Pitt martin.p...@ubuntu.com:
Colin Guthrie [2014-11-18 13:01 +]:
* I suppose even wich such a policy the post-installation script
still needs to call some systemd-update-policy-mumble-mumble magic
to actually apply the new policy?
Well, the
On Tue, Nov 18, 2014 at 4:21 PM, Didier Roche didro...@ubuntu.com wrote:
The thing I'm afraid of that we won't have a single place to list all
disable units, and they will be in multiple packages, so (as I'll repeat
below), I'm unsure that we would able to only load the preset as once shot,
as
On Tue, Nov 18, 2014 at 5:11 PM, Michael Biebl mbi...@gmail.com wrote:
2014-11-18 14:52 GMT+01:00 Martin Pitt martin.p...@ubuntu.com:
Colin Guthrie [2014-11-18 13:01 +]:
* I suppose even wich such a policy the post-installation script
still needs to call some
Michael Biebl wrote on 18/11/14 15:55:
2014-11-18 16:30 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
Michael Biebl wrote on 18/11/14 15:09:
2014-11-18 15:59 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
Didier Roche wrote on 18/11/14 13:58:
This would be maybe a nice way for the admin to
Le 18/11/2014 17:17, Tom Gundersen a écrit :
On Tue, Nov 18, 2014 at 4:21 PM, Didier Roche didro...@ubuntu.com wrote:
Let's say as an admin that I want to disable plymouth-quit.service (which is
a static unit file and symlinked in /usr/lib… on the multi-user target).
Without knowing the systemd
55 matches
Mail list logo
