Discussion:
[PATCH] [RFC] Remove installation of symlinks in /etc
(too old to reply)
Auke Kok
2013-02-12 00:34:27 UTC
Permalink
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks installing from git that want to override these settings
(either masking or otherwise).

Moving the links to $(systemunitdir) resolves.
---
Makefile.am | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 2cec04a..8945cfa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3622,8 +3622,8 @@ USER_UNIT_ALIASES += \
$(systemunitdir)/sound.target sound.target

GENERAL_ALIASES += \
- $(systemunitdir)/remote-fs.target $(pkgsysconfdir)/system/multi-user.target.wants/remote-fs.target \
- $(systemunitdir)/***@.service $(pkgsysconfdir)/system/getty.target.wants/***@tty1.service \
+ $(systemunitdir)/remote-fs.target $(systemunitdir)/multi-user.target.wants/remote-fs.target \
+ $(systemunitdir)/***@.service $(systemunitdir)/getty.target.wants/***@tty1.service \
$(pkgsysconfdir)/user $(sysconfdir)/xdg/systemd/user \
../system-services/org.freedesktop.systemd1.service $(dbussessionservicedir)/org.freedesktop.systemd1.service

@@ -3650,8 +3650,8 @@ INSTALL_DIRS += \
\
$(userunitdir) \
$(pkgsysconfdir)/system \
- $(pkgsysconfdir)/system/multi-user.target.wants \
- $(pkgsysconfdir)/system/getty.target.wants \
+ $(systemunitdir)/multi-user.target.wants \
+ $(systemunitdir)/getty.target.wants \
$(pkgsysconfdir)/user \
$(dbussessionservicedir) \
$(sysconfdir)/xdg/systemd
--
1.8.1
Umut Tezduyar
2013-02-12 12:00:29 UTC
Permalink
Hi,

If I am not mistaken, moving "***@tty1.service" and "remote-fs.target" to
$systemunitdir will cause them to be shown as "disabled" on "systemctl
status .unit" even though they are enabled. These unit files have
"[Install]" sections and when there is "[Install]" section on them, systemd
will look for a symbolic link in /etc to determine if the unit is
enabled/disabled.

If the mentioned unit files are moving to $systemunitdir, then their
[Install] section needs to be removed as well so systemd can treat them as
"static" unit files.

Thanks
Post by Auke Kok
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks installing from git that want to override these settings
(either masking or otherwise).
Moving the links to $(systemunitdir) resolves.
---
Makefile.am | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 2cec04a..8945cfa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3622,8 +3622,8 @@ USER_UNIT_ALIASES += \
$(systemunitdir)/sound.target sound.target
GENERAL_ALIASES += \
- $(systemunitdir)/remote-fs.target
$(pkgsysconfdir)/system/multi-user.target.wants/remote-fs.target \
+ $(systemunitdir)/remote-fs.target
$(systemunitdir)/multi-user.target.wants/remote-fs.target \
$(pkgsysconfdir)/user $(sysconfdir)/xdg/systemd/user \
../system-services/org.freedesktop.systemd1.service
$(dbussessionservicedir)/org.freedesktop.systemd1.service
@@ -3650,8 +3650,8 @@ INSTALL_DIRS += \
\
$(userunitdir) \
$(pkgsysconfdir)/system \
- $(pkgsysconfdir)/system/multi-user.target.wants \
- $(pkgsysconfdir)/system/getty.target.wants \
+ $(systemunitdir)/multi-user.target.wants \
+ $(systemunitdir)/getty.target.wants \
$(pkgsysconfdir)/user \
$(dbussessionservicedir) \
$(sysconfdir)/xdg/systemd
--
1.8.1
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Colin Guthrie
2013-02-12 21:12:39 UTC
Permalink
to $systemunitdir will cause them to be shown as "disabled" on
"systemctl status .unit" even though they are enabled. These unit files
have "[Install]" sections and when there is "[Install]" section on them,
systemd will look for a symbolic link in /etc to determine if the unit
is enabled/disabled.
If the mentioned unit files are moving to $systemunitdir, then their
[Install] section needs to be removed as well so systemd can treat them
as "static" unit files.
Should we not just drop them completely?

AFAIK, most distros don't ship those files but instead recreate them in
%post install scripts. Certainly, I've created distro-wide rpm-lint
rules that prevents any package from shipping any files inside
/etc/systemd/system/ (links or real units), and ditto for udev rules
etc. I'm very much trying to promote a tidy /etc these days :)

Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Kok, Auke-jan H
2013-02-12 21:35:05 UTC
Permalink
Post by Colin Guthrie
to $systemunitdir will cause them to be shown as "disabled" on
"systemctl status .unit" even though they are enabled. These unit files
have "[Install]" sections and when there is "[Install]" section on them,
systemd will look for a symbolic link in /etc to determine if the unit
is enabled/disabled.
If the mentioned unit files are moving to $systemunitdir, then their
[Install] section needs to be removed as well so systemd can treat them
as "static" unit files.
Should we not just drop them completely?
AFAIK, most distros don't ship those files but instead recreate them in
%post install scripts. Certainly, I've created distro-wide rpm-lint
rules that prevents any package from shipping any files inside
/etc/systemd/system/ (links or real units), and ditto for udev rules
etc. I'm very much trying to promote a tidy /etc these days :)
Eventually we can, and I would support that.

I was thinking of keeping them around since a lot of source-based
folks will not spot the difference and distros and SAs can now mask
them out and use an unpatched upstream release.

Either way fine with me, I just want them removed from /etc in the end.

Auke
Lennart Poettering
2013-02-13 00:21:00 UTC
Permalink
Post by Auke Kok
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks installing from git that want to override these settings
(either masking or otherwise).
Moving the links to $(systemunitdir) resolves.
I am not sure we really should do this. Both of these units should be
allowed to be disabled, and always telling people to mask them sounds a
bit too much...

Dunno, I am a bit split about this. I see where you are coming from, but
just making them static sounds like too simple...

(Also, if we make them static we'd drop the [Install] section, as that
would be pointless then...)

So, I am really unsure... Dunno... Opinions?
Post by Auke Kok
---
Makefile.am | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 2cec04a..8945cfa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3622,8 +3622,8 @@ USER_UNIT_ALIASES += \
$(systemunitdir)/sound.target sound.target
GENERAL_ALIASES += \
- $(systemunitdir)/remote-fs.target $(pkgsysconfdir)/system/multi-user.target.wants/remote-fs.target \
+ $(systemunitdir)/remote-fs.target $(systemunitdir)/multi-user.target.wants/remote-fs.target \
$(pkgsysconfdir)/user $(sysconfdir)/xdg/systemd/user \
../system-services/org.freedesktop.systemd1.service $(dbussessionservicedir)/org.freedesktop.systemd1.service
@@ -3650,8 +3650,8 @@ INSTALL_DIRS += \
\
$(userunitdir) \
$(pkgsysconfdir)/system \
- $(pkgsysconfdir)/system/multi-user.target.wants \
- $(pkgsysconfdir)/system/getty.target.wants \
+ $(systemunitdir)/multi-user.target.wants \
+ $(systemunitdir)/getty.target.wants \
$(pkgsysconfdir)/user \
$(dbussessionservicedir) \
$(sysconfdir)/xdg/systemd
Lennart
--
Lennart Poettering - Red Hat, Inc.
Kok, Auke-jan H
2013-02-13 00:25:41 UTC
Permalink
On Tue, Feb 12, 2013 at 4:21 PM, Lennart Poettering
Post by Lennart Poettering
Post by Auke Kok
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks installing from git that want to override these settings
(either masking or otherwise).
Moving the links to $(systemunitdir) resolves.
I am not sure we really should do this. Both of these units should be
allowed to be disabled, and always telling people to mask them sounds a
bit too much...
Dunno, I am a bit split about this. I see where you are coming from, but
just making them static sounds like too simple...
(Also, if we make them static we'd drop the [Install] section, as that
would be pointless then...)
So, I am really unsure... Dunno... Opinions?
then let's just remove them (the symlinks) altogether.

Auke
Lennart Poettering
2013-02-13 00:26:31 UTC
Permalink
Post by Kok, Auke-jan H
On Tue, Feb 12, 2013 at 4:21 PM, Lennart Poettering
Post by Lennart Poettering
Post by Auke Kok
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks installing from git that want to override these settings
(either masking or otherwise).
Moving the links to $(systemunitdir) resolves.
I am not sure we really should do this. Both of these units should be
allowed to be disabled, and always telling people to mask them sounds a
bit too much...
Dunno, I am a bit split about this. I see where you are coming from, but
just making them static sounds like too simple...
(Also, if we make them static we'd drop the [Install] section, as that
would be pointless then...)
So, I am really unsure... Dunno... Opinions?
then let's just remove them (the symlinks) altogether.
But that's even more brutal...

Also, I think it's nice if "make install" as a developer actually leaves
you with a working system where you still get a getty...

Lennart
--
Lennart Poettering - Red Hat, Inc.
Reindl Harald
2013-02-13 00:31:19 UTC
Permalink
Post by Lennart Poettering
Post by Auke Kok
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks installing from git that want to override these settings
(either masking or otherwise).
Moving the links to $(systemunitdir) resolves.
I am not sure we really should do this. Both of these units should be
allowed to be disabled, and always telling people to mask them sounds a
bit too much...
i want be able to disable "remote-fs.target" as example and i am
doing this regulary on a bunch of machines and would even like
to can "systemctl disable cryptsetup.target" for flexibility

folks installing from git should really not have a problem
Colin Guthrie
2013-02-13 15:00:46 UTC
Permalink
Post by Lennart Poettering
Post by Auke Kok
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks installing from git that want to override these settings
(either masking or otherwise).
Moving the links to $(systemunitdir) resolves.
I am not sure we really should do this. Both of these units should be
allowed to be disabled, and always telling people to mask them sounds a
bit too much...
Dunno, I am a bit split about this. I see where you are coming from, but
just making them static sounds like too simple...
(Also, if we make them static we'd drop the [Install] section, as that
would be pointless then...)
So, I am really unsure... Dunno... Opinions?
As a compromise, how about dropping them from "make install", but then
adding a new "make install-foo" rule that does install plus a few extra
bits and bobs so that those building from git can get their working
system easily without too much subsequent manual fiddling. Yes, this
requires those building and running from git know about "install-foo"
but I would hope such people are fairly competent and know at least
roughly what they are doing before taking such action anyway....

Obviously a better name than "foo" is needed. install-bootstrap?.

Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Richard Maw
2013-02-13 15:16:03 UTC
Permalink
Post by Colin Guthrie
Post by Lennart Poettering
Post by Auke Kok
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks installing from git that want to override these settings
(either masking or otherwise).
Moving the links to $(systemunitdir) resolves.
I am not sure we really should do this. Both of these units should be
allowed to be disabled, and always telling people to mask them sounds a
bit too much...
Dunno, I am a bit split about this. I see where you are coming from, but
just making them static sounds like too simple...
(Also, if we make them static we'd drop the [Install] section, as that
would be pointless then...)
So, I am really unsure... Dunno... Opinions?
As a compromise, how about dropping them from "make install", but then
adding a new "make install-foo" rule that does install plus a few extra
bits and bobs so that those building from git can get their working
system easily without too much subsequent manual fiddling. Yes, this
requires those building and running from git know about "install-foo"
but I would hope such people are fairly competent and know at least
roughly what they are doing before taking such action anyway....
Obviously a better name than "foo" is needed. install-bootstrap?.
How about testing whether DESTDIR is set?

If it is then it's usually intended to be packaged later, while if it's
not set then it's installed directly onto the system, at which point you
will want it to provide a bootable systemd.
Kok, Auke-jan H
2013-02-13 17:07:53 UTC
Permalink
On Wed, Feb 13, 2013 at 7:16 AM, Richard Maw
Post by Richard Maw
Post by Colin Guthrie
Post by Lennart Poettering
Post by Auke Kok
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks installing from git that want to override these settings
(either masking or otherwise).
Moving the links to $(systemunitdir) resolves.
I am not sure we really should do this. Both of these units should be
allowed to be disabled, and always telling people to mask them sounds a
bit too much...
Dunno, I am a bit split about this. I see where you are coming from, but
just making them static sounds like too simple...
(Also, if we make them static we'd drop the [Install] section, as that
would be pointless then...)
So, I am really unsure... Dunno... Opinions?
As a compromise, how about dropping them from "make install", but then
adding a new "make install-foo" rule that does install plus a few extra
bits and bobs so that those building from git can get their working
system easily without too much subsequent manual fiddling. Yes, this
requires those building and running from git know about "install-foo"
but I would hope such people are fairly competent and know at least
roughly what they are doing before taking such action anyway....
Obviously a better name than "foo" is needed. install-bootstrap?.
How about testing whether DESTDIR is set?
If it is then it's usually intended to be packaged later, while if it's
not set then it's installed directly onto the system, at which point you
will want it to provide a bootable systemd.
I'd actually argue that if DESTDIR is empty we're overwriting SA files
in /etc/, without the SA being able to prevent it.

Auke
Graham Cantin
2013-02-15 07:53:17 UTC
Permalink
Post by Colin Guthrie
Post by Lennart Poettering
Post by Auke Kok
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks installing from git that want to override these settings
(either masking or otherwise).
Moving the links to $(systemunitdir) resolves.
I am not sure we really should do this. Both of these units should be
allowed to be disabled, and always telling people to mask them sounds a
bit too much...
Dunno, I am a bit split about this. I see where you are coming from, but
just making them static sounds like too simple...
(Also, if we make them static we'd drop the [Install] section, as that
would be pointless then...)
So, I am really unsure... Dunno... Opinions?
As a compromise, how about dropping them from "make install", but then
adding a new "make install-foo" rule that does install plus a few extra
bits and bobs so that those building from git can get their working
system easily without too much subsequent manual fiddling. Yes, this
requires those building and running from git know about "install-foo"
but I would hope such people are fairly competent and know at least
roughly what they are doing before taking such action anyway....
Obviously a better name than "foo" is needed. install-bootstrap?.
How about the obvious? install-git?
Post by Colin Guthrie
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Tribalogic Limited http://www.tribalogic.net/
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
_______________________________________________
systemd-devel mailing list
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
[ Graham Cantin ] | (408) 890-7463 - Google Voice FindME
"You're arrogant for thinking you can, ignorant for thinking you cannot."
[ System Administrator ] | Secret Lair Labs - http://www.sllabs.com/
"As living spies we must recruit men who are intelligent but appear
to be stupid; who seem to be dull but are strong in heart; men who are
agile, vigorous, hardy, and brave; well-versed in lowly matters and able
to endure hunger, cold, filth, and humiliation." - Tu Mu (803-825)
Continue reading on narkive:
Loading...