Discussion:
[systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_message_get_cookie.xml man/sd_bus_new.xml man/sd_bus_open_user.xml man/sd_bus_request_name.xml src/libsystemd src/libsystemd-bus src/libsystemd-dhcp src/libsystemd-rtnl src/systemd TODO
(too old to reply)
Zbigniew Jędrzejewski-Szmek
2014-01-13 21:58:23 UTC
Permalink
commit 5681d7fb8be37771c152d21ea6e95597d664e3f1
Date: Mon Jan 13 21:03:28 2014 +0100
libsystemd-dns: merge into libsystemd
Also rename sd-dns -> sd-resolv.
Looks good.
commit 0b54473e9b73d867ed7807507a0fb5adc8137b10
Date: Mon Jan 13 20:14:44 2014 +0100
libsystemd-rtnl: merge into libsystemd
OK.
commit c813ca40c859ff8abc8bc6aabc3f1e896623eb67
Date: Mon Jan 13 19:12:16 2014 +0100
libsystemd-dhcp: merge into libsystemd
OK.
commit 6bb648a16ae4a682ad4784412af706d2e6a3e4da
Date: Mon Jan 13 17:30:51 2014 +0100
libsystemd-bus: rename to libsystemd
Documentation was updated to refer to either 'libsystemd' or 'sd-bus' in place
of libsystemd-bus.
Eeeh, why? This new name suggests that this libary is for systemd
functionality. But so far it is a generic. Also, we have
libsystemd-daemon, libsystemd-id128, etc. As a consumer of the library,
I'd much prefer to have it separated, if I'm using it for something not-systemd
related.

Zbyszek
Kay Sievers
2014-01-14 01:00:01 UTC
Permalink
On Tue, Jan 14, 2014 at 5:58 AM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
libsystemd-bus: rename to libsystemd
Documentation was updated to refer to either 'libsystemd' or 'sd-bus' in place
of libsystemd-bus.
Eeeh, why? This new name suggests that this libary is for systemd
functionality. But so far it is a generic. Also, we have
libsystemd-daemon, libsystemd-id128, etc. As a consumer of the library,
I'd much prefer to have it separated, if I'm using it for something not-systemd
related.
We decided that all these libs will all end up in that one single .so,
also the journal.

Otherwise we will not be able to manage the cyclic deps all this will
create with logging and bus communication and name resolving.

This lib could be called differently, but it will be the same outcome.

Kay
Thomas H.P. Andersen
2014-01-14 07:25:53 UTC
Permalink
On Mon, Jan 13, 2014 at 10:58 PM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
commit 5681d7fb8be37771c152d21ea6e95597d664e3f1
Date: Mon Jan 13 21:03:28 2014 +0100
libsystemd-dns: merge into libsystemd
Also rename sd-dns -> sd-resolv.
Looks good.
Does -lresolv belong in libsystemd_la_CFLAGS? I would have thought
that it should be in LIBADD for the lib and LDADD for the test.
Kay Sievers
2014-01-14 08:06:38 UTC
Permalink
On Tue, Jan 14, 2014 at 5:58 AM, Zbigniew Jędrzejewski-Szmek
commit c813ca40c859ff8abc8bc6aabc3f1e896623eb67
Date: Mon Jan 13 19:12:16 2014 +0100
libsystemd-dhcp: merge into libsystemd
OK.
Hmm, maybe DHCP should stay as a separate lib? We should not run into
cyclic dependency problems here, and we could argue that DHCP is not a
"core" feature, but rather an add-on?

Kay
Lennart Poettering
2014-01-16 15:41:48 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Eeeh, why? This new name suggests that this libary is for systemd
functionality. But so far it is a generic. Also, we have
libsystemd-daemon, libsystemd-id128, etc. As a consumer of the library,
I'd much prefer to have it separated, if I'm using it for something not-systemd
related.
So, this is really hard to keep seperate. The thing is that much of this
is such basic functionality that the libraries require that
functionality from each other. For example, it's certainly a good idea
to provide sd-event hookup for all our libraries that can integrate in
an event loop. WHich would suggest we'd make all those libraries depend
on libsystemd-bus. But then, we'd also like to make use of the calls
from libsystemd-login from sd-bus, since we provide
sd_bus_creds_new_from_pid() and friends. And there you have your cyclic
dep... And this is the smae for id128 and the others....

(We currently avoid these issues via a varity of unsatisfactory hacks:
for example, we don't provide any sd-event integration, and expect
consumers to do this on their own. Or, for the libsystemd-login case we
actually have the real code in src/shared/cgroup-util.c and have
libsystemd-login just a thin wrapper around it)

There are more problems this generates, for example, we link all of
src/shared/*.c into each of these libs, and then let the linker remove
all functions agin that are unused by the specific libs. This sounds
nice, but actually just means that a lot of functions are in memory a
number of times because they exist the same way in all our libraries.
This is sometimes quite ridiculous, for example for libsystemd-id128
which is kinda trivial but still pulls in a copy of its own of much of
src/shared/*.c.

So I am pretty sure libsystemd-id128, libsystemd-login,
libsystemd-journal should just end up in a single libsystemd.so together
with the event loop, the bus, the asyncns stuff and more. All this
functinality requires each other, and should nto pull in its own copy of
src/shared/*.c each time.

There are some exceptions to this though. For example, I am unsure about
libsystemd-daemon: it's relatively easy to maintain this in its own lib,
sicne so far it actually doesn't use any of the shared code, because
its' embeddable. But then agaiun, given that this library evolves too,
and given that distros generally don't like embedding anyway, we should
probably just merge it into libsystemd.so too, in particular since the
functions it provides are really low-level stuff. libsystemd-dhcp
however really sounds like something that will always be consumer of services, never
provider of services from this new libsystemd.so, and the set of
programs making use of it will always be very small, so we can and
should certainly keep it a seperate lib.

I hope this makes some sense...

Lennart
--
Lennart Poettering, Red Hat
Zbigniew Jędrzejewski-Szmek
2014-01-16 16:24:02 UTC
Permalink
Post by Lennart Poettering
Post by Zbigniew Jędrzejewski-Szmek
Eeeh, why? This new name suggests that this libary is for systemd
functionality. But so far it is a generic. Also, we have
libsystemd-daemon, libsystemd-id128, etc. As a consumer of the library,
I'd much prefer to have it separated, if I'm using it for something not-systemd
related.
So, this is really hard to keep seperate. The thing is that much of this
is such basic functionality that the libraries require that
functionality from each other. For example, it's certainly a good idea
to provide sd-event hookup for all our libraries that can integrate in
an event loop. WHich would suggest we'd make all those libraries depend
on libsystemd-bus. But then, we'd also like to make use of the calls
from libsystemd-login from sd-bus, since we provide
sd_bus_creds_new_from_pid() and friends. And there you have your cyclic
dep... And this is the smae for id128 and the others....
for example, we don't provide any sd-event integration, and expect
consumers to do this on their own. Or, for the libsystemd-login case we
actually have the real code in src/shared/cgroup-util.c and have
libsystemd-login just a thin wrapper around it)
There are more problems this generates, for example, we link all of
src/shared/*.c into each of these libs, and then let the linker remove
all functions agin that are unused by the specific libs. This sounds
nice, but actually just means that a lot of functions are in memory a
number of times because they exist the same way in all our libraries.
This is sometimes quite ridiculous, for example for libsystemd-id128
which is kinda trivial but still pulls in a copy of its own of much of
src/shared/*.c.
So I am pretty sure libsystemd-id128, libsystemd-login,
libsystemd-journal should just end up in a single libsystemd.so together
with the event loop, the bus, the asyncns stuff and more. All this
functinality requires each other, and should nto pull in its own copy of
src/shared/*.c each time.
There are some exceptions to this though. For example, I am unsure about
libsystemd-daemon: it's relatively easy to maintain this in its own lib,
sicne so far it actually doesn't use any of the shared code, because
its' embeddable. But then agaiun, given that this library evolves too,
and given that distros generally don't like embedding anyway, we should
probably just merge it into libsystemd.so too, in particular since the
functions it provides are really low-level stuff. libsystemd-dhcp
however really sounds like something that will always be consumer of services, never
provider of services from this new libsystemd.so, and the set of
programs making use of it will always be very small, so we can and
should certainly keep it a seperate lib.
I hope this makes some sense...
Yes, it does. Thank you for the nice summary.

I am also a bit worried about so-bumps: currently we have very nice backwards
compatibility, without any API removals. -daemon, -id128, -journal, -login
are all still .so.0. But libsystemd-bus (libsystemd now) is much harder to
keep this way, among other reasons, because it's much bigger, and much more
experimental.

Zbyszek
Michael Biebl
2014-01-16 16:33:28 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
I am also a bit worried about so-bumps: currently we have very nice backwards
compatibility, without any API removals. -daemon, -id128, -journal, -login
are all still .so.0. But libsystemd-bus (libsystemd now) is much harder to
keep this way, among other reasons, because it's much bigger, and much more
experimental.
I'd prefer if the libraries were kept separate, at least for the ones
for which it is possible without it beeing to painful.
At least libsytemd-daemon should imho be kept separate with a stable API/ABI.
We already have 10+ reverse dependencies of that library in Debian and
the list is constantly growing.
So not having to go through soname transitions affecting potentially
quite a few packages would definitely be a big plus.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Lennart Poettering
2014-01-16 16:56:49 UTC
Permalink
Post by Michael Biebl
Post by Zbigniew Jędrzejewski-Szmek
I am also a bit worried about so-bumps: currently we have very nice backwards
compatibility, without any API removals. -daemon, -id128, -journal, -login
are all still .so.0. But libsystemd-bus (libsystemd now) is much harder to
keep this way, among other reasons, because it's much bigger, and much more
experimental.
I'd prefer if the libraries were kept separate, at least for the ones
for which it is possible without it beeing to painful.
At least libsytemd-daemon should imho be kept separate with a stable API/ABI.
We already have 10+ reverse dependencies of that library in Debian and
the list is constantly growing.
Sure, but as mentioned, if we end up merging libsystemd-daemon.so into
libsystemd.so, both would be parallel installable and would not result
in symbol clashes. Thus, the transition should be smooth... (Also note
that it would still be the same scope, so if you are concerned about
pulling in incompatible code into non-systemd boots, there's shouldn't
be a problem)
Post by Michael Biebl
So not having to go through soname transitions affecting potentially
quite a few packages would definitely be a big plus.
Well, Debian is much better at doing smooth soname transitions, since it
encodes the soname in the package name. With the symbol versioning we do
this should really avoid any troubles...

Lennart
--
Lennart Poettering, Red Hat
Michael Biebl
2014-01-16 17:27:55 UTC
Permalink
Post by Lennart Poettering
Post by Michael Biebl
Post by Zbigniew Jędrzejewski-Szmek
I am also a bit worried about so-bumps: currently we have very nice backwards
compatibility, without any API removals. -daemon, -id128, -journal, -login
are all still .so.0. But libsystemd-bus (libsystemd now) is much harder to
keep this way, among other reasons, because it's much bigger, and much more
experimental.
I'd prefer if the libraries were kept separate, at least for the ones
for which it is possible without it beeing to painful.
At least libsytemd-daemon should imho be kept separate with a stable API/ABI.
We already have 10+ reverse dependencies of that library in Debian and
the list is constantly growing.
Sure, but as mentioned, if we end up merging libsystemd-daemon.so into
libsystemd.so, both would be parallel installable and would not result
in symbol clashes. Thus, the transition should be smooth... (Also note
that it would still be the same scope, so if you are concerned about
pulling in incompatible code into non-systemd boots, there's shouldn't
be a problem)
Well, since you plan to drop the .pc files I wouldn't really call the
transition smooth, as every package would need sourceful changes to
their configure check to now use a different .pc file name.

Having to touch every affected package is something I'd like to avoid
especially since I don't quite see the benefit of folding libsd-daemon
into libsd.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Lennart Poettering
2014-01-16 17:37:20 UTC
Permalink
Post by Michael Biebl
Post by Lennart Poettering
Post by Michael Biebl
Post by Zbigniew Jędrzejewski-Szmek
I am also a bit worried about so-bumps: currently we have very nice backwards
compatibility, without any API removals. -daemon, -id128, -journal, -login
are all still .so.0. But libsystemd-bus (libsystemd now) is much harder to
keep this way, among other reasons, because it's much bigger, and much more
experimental.
I'd prefer if the libraries were kept separate, at least for the ones
for which it is possible without it beeing to painful.
At least libsytemd-daemon should imho be kept separate with a stable API/ABI.
We already have 10+ reverse dependencies of that library in Debian and
the list is constantly growing.
Sure, but as mentioned, if we end up merging libsystemd-daemon.so into
libsystemd.so, both would be parallel installable and would not result
in symbol clashes. Thus, the transition should be smooth... (Also note
that it would still be the same scope, so if you are concerned about
pulling in incompatible code into non-systemd boots, there's shouldn't
be a problem)
Well, since you plan to drop the .pc files I wouldn't really call the
transition smooth, as every package would need sourceful changes to
their configure check to now use a different .pc file name.
Well, it can certainly continue to use and build against the old version
for a while, no?
Post by Michael Biebl
Having to touch every affected package is something I'd like to avoid
especially since I don't quite see the benefit of folding libsd-daemon
into libsd.
Well, we currently do a lot of stuff manually in sd-daemon.c which
if merged (and with the embeddability requirement dropped) we could just
use functions from util.c for. (Remember that sd_notify() discussion on
debian's ctte ML, where some people got irritated by the perceived
complexity of the function...?) Also, the library evolves. For example,
I recently added calls to simplify the WATCHDOG_USEC stuff to the lib,
and sooner or later it just gets annoying to hack these new things
without src/shared/*.c available...

I mean, that's probably the key issue here:

Hacking with src/shared/*.c and with _cleanup_ and other gcc macros
defined is fun. Hacking without it is so much nastier these days... I
really am put off by that nowawadays. It's probably the one big reason
why I am doing such a shitty job at Avahi maintaining these days:
hacking without the luxury of the systemd internal APIs and syntactic
sugar is just not fun anymore...

Lennart
--
Lennart Poettering, Red Hat
Michael Biebl
2014-01-16 18:00:56 UTC
Permalink
Post by Lennart Poettering
Post by Michael Biebl
Post by Lennart Poettering
Post by Michael Biebl
Post by Zbigniew Jędrzejewski-Szmek
I am also a bit worried about so-bumps: currently we have very nice backwards
compatibility, without any API removals. -daemon, -id128, -journal, -login
are all still .so.0. But libsystemd-bus (libsystemd now) is much harder to
keep this way, among other reasons, because it's much bigger, and much more
experimental.
I'd prefer if the libraries were kept separate, at least for the ones
for which it is possible without it beeing to painful.
At least libsytemd-daemon should imho be kept separate with a stable API/ABI.
We already have 10+ reverse dependencies of that library in Debian and
the list is constantly growing.
Sure, but as mentioned, if we end up merging libsystemd-daemon.so into
libsystemd.so, both would be parallel installable and would not result
in symbol clashes. Thus, the transition should be smooth... (Also note
that it would still be the same scope, so if you are concerned about
pulling in incompatible code into non-systemd boots, there's shouldn't
be a problem)
Well, since you plan to drop the .pc files I wouldn't really call the
transition smooth, as every package would need sourceful changes to
their configure check to now use a different .pc file name.
Well, it can certainly continue to use and build against the old version
for a while, no?
We'd have to make pre-systemd-209 and systemd-209 packages
co-installable (different source package names etc.) to be able to
continue to provide the old version. That is not really fun.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Kay Sievers
2014-01-16 18:17:22 UTC
Permalink
Post by Michael Biebl
Post by Lennart Poettering
Well, it can certainly continue to use and build against the old version
for a while, no?
We'd have to make pre-systemd-209 and systemd-209 packages
co-installable (different source package names etc.) to be able to
continue to provide the old version. That is not really fun.
Why? The lib is packaged separately, isn't it? What does it have to do
with the systemd package?

Kay
Michael Biebl
2014-01-16 18:22:44 UTC
Permalink
Post by Kay Sievers
Post by Michael Biebl
Post by Lennart Poettering
Well, it can certainly continue to use and build against the old version
for a while, no?
We'd have to make pre-systemd-209 and systemd-209 packages
co-installable (different source package names etc.) to be able to
continue to provide the old version. That is not really fun.
Why? The lib is packaged separately, isn't it? What does it have to do
with the systemd package?
Packaged separately in the sense that the systemd source package
builds a libsystemd-daemon0 binary package (among others).
In systemd v209 we could no longer build such a libsystemd-daemon0
binary package from the systemd source package.
We'd have to introduce a separate source package (based on systemd pre
209) named differently then systemd if we want to be able to continue
to build libsystemd-daemon0.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Colin Guthrie
2014-01-16 21:36:47 UTC
Permalink
Post by Michael Biebl
Post by Kay Sievers
Post by Michael Biebl
Post by Lennart Poettering
Well, it can certainly continue to use and build against the old version
for a while, no?
We'd have to make pre-systemd-209 and systemd-209 packages
co-installable (different source package names etc.) to be able to
continue to provide the old version. That is not really fun.
Why? The lib is packaged separately, isn't it? What does it have to do
with the systemd package?
Packaged separately in the sense that the systemd source package
builds a libsystemd-daemon0 binary package (among others).
In systemd v209 we could no longer build such a libsystemd-daemon0
binary package from the systemd source package.
We'd have to introduce a separate source package (based on systemd pre
209) named differently then systemd if we want to be able to continue
to build libsystemd-daemon0.
Could we not provide a libsystemd-daemon.so.0 that is just a stub and
links to libsystemd.so.X and just calls the functions therein? That way
the API could still be provided with the old lib (and old .pc files too)
until such times as everything is updated. I would presume the name
mangling would allow for this to work OK with some clever tricks here
and there... (correctly me if I'm wrong)

This would surely be the nicest way to handle things during any
transition phase and could be turned off with a configure switch?

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/
Zbigniew Jędrzejewski-Szmek
2014-01-17 03:06:00 UTC
Permalink
Post by Colin Guthrie
Post by Michael Biebl
Post by Kay Sievers
Post by Michael Biebl
Post by Lennart Poettering
Well, it can certainly continue to use and build against the old version
for a while, no?
So there's "binary" compatibility, and "source" compatibility.
It would be nice if we could do those changes without

a) requiring recompilation ("binary")
b) requiring editing build scripts in dependent packages ("source").

For b, keeping around a .pc file which points to the *new* library
name should be enough:

- Libs: -L${libdir} -lsystemd-login
+ Libs: -L${libdir} -lsystemd

On our side it's a tiny effort, and avoid a major PITA for distributions.

For a, a compatibility symlink (e.g. libsystemd-login.so.0 -> libsystemd.so.0)
can be provided. I'm attaching a POC patch which moves the symbol exports
so that programs compiled against libsystemd-login will continue working.
The symlink is not created, this part must be done by hand.

I think that if we ever decide to futher merge libraries, those
would be the steps to take.
Post by Colin Guthrie
Post by Michael Biebl
Post by Kay Sievers
Post by Michael Biebl
We'd have to make pre-systemd-209 and systemd-209 packages
co-installable (different source package names etc.) to be able to
continue to provide the old version. That is not really fun.
Why? The lib is packaged separately, isn't it? What does it have to do
with the systemd package?
Packaged separately in the sense that the systemd source package
builds a libsystemd-daemon0 binary package (among others).
In systemd v209 we could no longer build such a libsystemd-daemon0
binary package from the systemd source package.
We'd have to introduce a separate source package (based on systemd pre
209) named differently then systemd if we want to be able to continue
to build libsystemd-daemon0.
Could we not provide a libsystemd-daemon.so.0 that is just a stub and
links to libsystemd.so.X and just calls the functions therein? That way
the API could still be provided with the old lib (and old .pc files too)
until such times as everything is updated. I would presume the name
mangling would allow for this to work OK with some clever tricks here
and there... (correctly me if I'm wrong)
Yes, I think that's the way to go.
Post by Colin Guthrie
This would surely be the nicest way to handle things during any
transition phase and could be turned off with a configure switch?
Zbyszek
Zbigniew Jędrzejewski-Szmek
2014-01-17 03:07:15 UTC
Permalink
---
Makefile.am | 73 +++++--------------------------
src/libsystemd/libsystemd.sym | 87 +++++++++++++++++++++++++++++++++++--
src/login/libsystemd-login.pc.in | 2 +-
src/login/libsystemd-login.sym | 94 ----------------------------------------
4 files changed, 97 insertions(+), 159 deletions(-)
delete mode 100644 src/login/libsystemd-login.sym

diff --git a/Makefile.am b/Makefile.am
index 4fce9d6..4511d24 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1795,11 +1795,6 @@ systemctl_LDADD = \
libsystemd-internal.la \
libsystemd-logs.la

-if ENABLE_LOGIND
-systemctl_LDADD += \
- libsystemd-login-internal.la
-endif
-
systemctl_LDADD += \
libsystemd-journal-internal.la \
libsystemd-id128-internal.la \
@@ -2027,7 +2022,11 @@ libsystemd_la_SOURCES = \
src/libsystemd/rtnl-util.h \
src/libsystemd/rtnl-util.c \
src/libsystemd/sd-resolve.c \
- src/libsystemd/resolve-util.h
+ src/libsystemd/resolve-util.h \
+ src/login/sd-login.c \
+ src/systemd/sd-login.h \
+ src/login/login-shared.c \
+ src/login/login-shared.h

nodist_libsystemd_la_SOURCES = \
src/libsystemd/bus-error-mapping.c
@@ -3258,11 +3257,6 @@ libsystemd_journal_core_la_LIBADD = \
libsystemd-id128-internal.la \
libsystemd-shared.la

-if ENABLE_LOGIND
-libsystemd_journal_core_la_LIBADD += \
- libsystemd-login-internal.la
-endif
-
if HAVE_ACL
libsystemd_journal_core_la_LIBADD += \
libsystemd-acl.la
@@ -3460,12 +3454,8 @@ systemd_coredump_SOURCES = \
systemd_coredump_LDADD = \
libsystemd-journal-internal.la \
libsystemd-label.la \
- libsystemd-shared.la
-
-if ENABLE_LOGIND
-systemd_coredump_LDADD += \
- libsystemd-login-internal.la
-endif
+ libsystemd-shared.la \
+ libsystemd-internal.la

rootlibexec_PROGRAMS += \
systemd-coredump
@@ -4226,14 +4216,14 @@ test_login_SOURCES = \
src/login/test-login.c

test_login_LDADD = \
- libsystemd-login-internal.la \
+ libsystemd-internal.la \
libsystemd-shared.la

test_login_shared_SOURCES = \
src/login/test-login-shared.c

test_login_shared_LDADD = \
- libsystemd-login-internal.la \
+ libsystemd-internal.la \
libsystemd-shared.la

test_inhibit_SOURCES = \
@@ -4259,29 +4249,6 @@ tests += \
test-login-tables \
test-login-shared

-libsystemd_login_la_SOURCES = \
- src/login/libsystemd-login.sym \
- src/login/sd-login.c \
- src/systemd/sd-login.h \
- src/login/login-shared.c \
- src/login/login-shared.h
-
-libsystemd_login_la_CFLAGS = \
- $(AM_CFLAGS) \
- -fvisibility=hidden
-
-libsystemd_login_la_LDFLAGS = \
- $(AM_LDFLAGS) \
- -version-info $(LIBSYSTEMD_LOGIN_CURRENT):$(LIBSYSTEMD_LOGIN_REVISION):$(LIBSYSTEMD_LOGIN_AGE) \
- -Wl,--version-script=$(top_srcdir)/src/login/libsystemd-login.sym
-
-libsystemd_login_la_LIBADD = \
- libsystemd-daemon-internal.la \
- libsystemd-shared.la
-
-libsystemd_login_internal_la_SOURCES = \
- $(libsystemd_login_la_SOURCES)
-
if HAVE_PAM
pam_systemd_la_SOURCES = \
src/login/pam-module.c
@@ -4344,12 +4311,6 @@ dist_pkgsysconf_DATA += \
pkginclude_HEADERS += \
src/systemd/sd-login.h

-lib_LTLIBRARIES += \
- libsystemd-login.la
-
-noinst_LTLIBRARIES += \
- libsystemd-login-internal.la
-
pkgconfiglib_DATA += \
src/login/libsystemd-login.pc

@@ -4520,7 +4481,7 @@ login_la_LDFLAGS = \
login_la_LIBADD = \
$(PYTHON_DEVEL_LIBS) \
libsystemd-journal.la \
- libsystemd-login.la \
+ libsystemd.la \
libsystemd-daemon-internal.la \
libsystemd-shared.la

@@ -4980,7 +4941,8 @@ endef
test-libsystemd-sym.c: \
src/libsystemd/libsystemd.sym \
src/systemd/sd-bus.h \
- src/systemd/sd-utf8.h
+ src/systemd/sd-utf8.h \
+ src/systemd/sd-login.h
$(generate-sym-test)

test-libsystemd-daemon-sym.c: \
@@ -4998,11 +4960,6 @@ test-libsystemd-journal-sym.c: \
src/systemd/sd-journal.h
$(generate-sym-test)

-test-libsystemd-login-sym.c: \
- src/login/libsystemd-login.sym \
- src/systemd/sd-login.h
- $(generate-sym-test)
-
test-libudev-sym.c: \
src/libudev/libudev.sym \
src/udev/udev.h
@@ -5028,11 +4985,6 @@ test_libsystemd_journal_sym_SOURCES = \
test_libsystemd_journal_sym_LDADD = \
libsystemd-journal.la

-test_libsystemd_login_sym_SOURCES = \
- test-libsystemd-login-sym.c
-test_libsystemd_login_sym_LDADD = \
- libsystemd-login.la
-
test_libudev_sym_SOURCES = \
test-libudev-sym.c
test_libudev_sym_LDADD = \
@@ -5051,7 +5003,6 @@ tests += \
test-libsystemd-daemon-sym \
test-libsystemd-id128-sym \
test-libsystemd-journal-sym \
- test-libsystemd-login-sym \
test-libudev-sym

cppcheck:
diff --git a/src/libsystemd/libsystemd.sym b/src/libsystemd/libsystemd.sym
index 1fb6690..f286e16 100644
--- a/src/libsystemd/libsystemd.sym
+++ b/src/libsystemd/libsystemd.sym
@@ -7,8 +7,91 @@
(at your option) any later version.
***/

+/* Original symbols from systemd v31 */
+
+LIBSYSTEMD_LOGIN_31 {
+global:
+ sd_get_seats;
+ sd_get_sessions;
+ sd_get_uids;
+ sd_login_monitor_flush;
+ sd_login_monitor_get_fd;
+ sd_login_monitor_new;
+ sd_login_monitor_unref;
+ sd_pid_get_owner_uid;
+ sd_pid_get_session;
+ sd_seat_can_multi_session;
+ sd_seat_get_active;
+ sd_seat_get_sessions;
+ sd_session_get_seat;
+ sd_session_get_uid;
+ sd_session_is_active;
+ sd_uid_get_seats;
+ sd_uid_get_sessions;
+ sd_uid_get_state;
+ sd_uid_is_on_seat;
+local:
+ *;
+};
+
+LIBSYSTEMD_LOGIN_38 {
+global:
+ sd_pid_get_unit;
+ sd_session_get_service;
+} LIBSYSTEMD_LOGIN_31;
+
+LIBSYSTEMD_LOGIN_43 {
+global:
+ sd_session_get_type;
+ sd_session_get_class;
+ sd_session_get_display;
+} LIBSYSTEMD_LOGIN_38;
+
+LIBSYSTEMD_LOGIN_186 {
+global:
+ sd_session_get_state;
+ sd_seat_can_tty;
+ sd_seat_can_graphical;
+} LIBSYSTEMD_LOGIN_43;
+
+LIBSYSTEMD_LOGIN_198 {
+global:
+ sd_session_get_tty;
+} LIBSYSTEMD_LOGIN_186;
+
+LIBSYSTEMD_LOGIN_201 {
+global:
+ sd_login_monitor_get_events;
+ sd_login_monitor_get_timeout;
+} LIBSYSTEMD_LOGIN_198;
+
+LIBSYSTEMD_LOGIN_202 {
+global:
+ sd_pid_get_user_unit;
+ sd_pid_get_machine_name;
+} LIBSYSTEMD_LOGIN_201;
+
+LIBSYSTEMD_LOGIN_203 {
+global:
+ sd_get_machine_names;
+} LIBSYSTEMD_LOGIN_202;
+
+LIBSYSTEMD_LOGIN_205 {
+global:
+ sd_pid_get_slice;
+} LIBSYSTEMD_LOGIN_203;
+
+LIBSYSTEMD_LOGIN_207 {
+global:
+ sd_session_get_vt;
+} LIBSYSTEMD_LOGIN_205;
+
LIBSYSTEMD_BUS_209 {
global:
+ sd_session_is_remote;
+ sd_session_get_remote_user;
+ sd_session_get_remote_host;
+
/* Same order as in sd-bus.h should be used */

/* Connections */
@@ -270,6 +353,4 @@ global:
sd_utf8_is_valid;
sd_ascii_is_valid;

-local:
- *;
-};
+} LIBSYSTEMD_LOGIN_207;
diff --git a/src/login/libsystemd-login.pc.in b/src/login/libsystemd-login.pc.in
index 7b2a724..0decb6c 100644
--- a/src/login/libsystemd-login.pc.in
+++ b/src/login/libsystemd-login.pc.in
@@ -14,5 +14,5 @@ Name: systemd
Description: systemd Login Utility Library
URL: @PACKAGE_URL@
Version: @PACKAGE_VERSION@
-Libs: -L${libdir} -lsystemd-login
+Libs: -L${libdir} -lsystemd
Cflags: -I${includedir}
diff --git a/src/login/libsystemd-login.sym b/src/login/libsystemd-login.sym
deleted file mode 100644
index 1d33982..0000000
--- a/src/login/libsystemd-login.sym
+++ /dev/null
@@ -1,94 +0,0 @@
-/***
- This file is part of systemd.
-
- systemd is free software; you can redistribute it and/or modify it
- under the terms of the GNU Lesser General Public License as published by
- the Free Software Foundation; either version 2.1 of the License, or
- (at your option) any later version.
-***/
-
-/* Original symbols from systemd v31 */
-
-LIBSYSTEMD_LOGIN_31 {
-global:
- sd_get_seats;
- sd_get_sessions;
- sd_get_uids;
- sd_login_monitor_flush;
- sd_login_monitor_get_fd;
- sd_login_monitor_new;
- sd_login_monitor_unref;
- sd_pid_get_owner_uid;
- sd_pid_get_session;
- sd_seat_can_multi_session;
- sd_seat_get_active;
- sd_seat_get_sessions;
- sd_session_get_seat;
- sd_session_get_uid;
- sd_session_is_active;
- sd_uid_get_seats;
- sd_uid_get_sessions;
- sd_uid_get_state;
- sd_uid_is_on_seat;
-local:
- *;
-};
-
-LIBSYSTEMD_LOGIN_38 {
-global:
- sd_pid_get_unit;
- sd_session_get_service;
-} LIBSYSTEMD_LOGIN_31;
-
-LIBSYSTEMD_LOGIN_43 {
-global:
- sd_session_get_type;
- sd_session_get_class;
- sd_session_get_display;
-} LIBSYSTEMD_LOGIN_38;
-
-LIBSYSTEMD_LOGIN_186 {
-global:
- sd_session_get_state;
- sd_seat_can_tty;
- sd_seat_can_graphical;
-} LIBSYSTEMD_LOGIN_43;
-
-LIBSYSTEMD_LOGIN_198 {
-global:
- sd_session_get_tty;
-} LIBSYSTEMD_LOGIN_186;
-
-LIBSYSTEMD_LOGIN_201 {
-global:
- sd_login_monitor_get_events;
- sd_login_monitor_get_timeout;
-} LIBSYSTEMD_LOGIN_198;
-
-LIBSYSTEMD_LOGIN_202 {
-global:
- sd_pid_get_user_unit;
- sd_pid_get_machine_name;
-} LIBSYSTEMD_LOGIN_201;
-
-LIBSYSTEMD_LOGIN_203 {
-global:
- sd_get_machine_names;
-} LIBSYSTEMD_LOGIN_202;
-
-LIBSYSTEMD_LOGIN_205 {
-global:
- sd_pid_get_slice;
-} LIBSYSTEMD_LOGIN_203;
-
-LIBSYSTEMD_LOGIN_207 {
-global:
- sd_session_get_vt;
-} LIBSYSTEMD_LOGIN_205;
-
-LIBSYSTEMD_LOGIN_209 {
-global:
- sd_session_is_remote;
- sd_session_get_remote_user;
- sd_session_get_remote_host;
-} LIBSYSTEMD_LOGIN_207;
--
1.8.4.2
Kay Sievers
2014-01-17 08:02:19 UTC
Permalink
On Fri, Jan 17, 2014 at 4:07 AM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
--- a/src/libsystemd/libsystemd.sym
+++ b/src/libsystemd/libsystemd.sym
@@ -7,8 +7,91 @@
(at your option) any later version.
***/
+/* Original symbols from systemd v31 */
+
+LIBSYSTEMD_LOGIN_31 {
Do I get this right? This exports the exact same symbols from the new lib?

This does not sound right. We should not try to be too smart here.

Symbol versions are supposed to avoid exactly the problem this will
create. The old symbols should not be provided by the new lib, to
allow the loading of the old and new lib into the same process without
clashes. We have no control which library is linked in over other
dependencies, it's very easy to end up with both libs in one process,
just by linking a third unrelated lib.

If backwards-compat is needed, it should be provided by a compat
package shipping the old lib, and not by double-exporting symbols from
the old and the new lib at the same time.

All this is nothing else in behavior than a SONAME bump, which is a
very common task for distros to solve. Actually it's exactly what a
distro is for, to solve these sorts of problems. Upstream packages
should not try to do magic things here, it just makes things too
fragile in the end.

Kay
Kay Sievers
2014-01-17 09:32:17 UTC
Permalink
Post by Kay Sievers
On Fri, Jan 17, 2014 at 4:07 AM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
--- a/src/libsystemd/libsystemd.sym
+++ b/src/libsystemd/libsystemd.sym
@@ -7,8 +7,91 @@
(at your option) any later version.
***/
+/* Original symbols from systemd v31 */
+
+LIBSYSTEMD_LOGIN_31 {
Do I get this right? This exports the exact same symbols from the new lib?
This does not sound right. We should not try to be too smart here.
Symbol versions are supposed to avoid exactly the problem this will
create. The old symbols should not be provided by the new lib, to
allow the loading of the old and new lib into the same process without
clashes. We have no control which library is linked in over other
dependencies, it's very easy to end up with both libs in one process,
just by linking a third unrelated lib.
If backwards-compat is needed, it should be provided by a compat
package shipping the old lib, and not by double-exporting symbols from
the old and the new lib at the same time.
All this is nothing else in behavior than a SONAME bump, which is a
very common task for distros to solve. Actually it's exactly what a
distro is for, to solve these sorts of problems. Upstream packages
should not try to do magic things here, it just makes things too
fragile in the end.
What might work out instead is adding all the symbols of the libs we
want to merge to libsystemd.so, with its _correct_ symbol version
prefix LIBSYSTEMD_209, leave the original libs untouched and
standalone, not even try to do any stub wrapping.

Distros then should change the current users to the new lib and
recompile. After that, with the next release, we will remove the old
libs and have only libsystemd.so and the new names in the systemd
sources.

After that point, distros can still provide the old lib packages as
long as needed, if they care, but upstream defaults would be without
any weird magic or SONAME or file name clashes.

Kay
Kay Sievers
2014-01-17 08:18:49 UTC
Permalink
On Fri, Jan 17, 2014 at 4:06 AM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
So there's "binary" compatibility, and "source" compatibility.
It would be nice if we could do those changes without
a) requiring recompilation ("binary")
b) requiring editing build scripts in dependent packages ("source").
For b, keeping around a .pc file which points to the *new* library
- Libs: -L${libdir} -lsystemd-login
+ Libs: -L${libdir} -lsystemd
On our side it's a tiny effort, and avoid a major PITA for distributions.
No, it will clash with the files from the old lib package. We should
not do that, if we no longer provide the same lib.
Post by Zbigniew Jędrzejewski-Szmek
For a, a compatibility symlink (e.g. libsystemd-login.so.0 -> libsystemd.so.0)
can be provided. I'm attaching a POC patch which moves the symbol exports
so that programs compiled against libsystemd-login will continue working.
The symlink is not created, this part must be done by hand.
I think that if we ever decide to futher merge libraries, those
would be the steps to take.
Same here, it creates clashes with the old files and is not strictly
what it pretends to be with the symlink name.
Post by Zbigniew Jędrzejewski-Szmek
Post by Colin Guthrie
Could we not provide a libsystemd-daemon.so.0 that is just a stub and
links to libsystemd.so.X and just calls the functions therein? That way
the API could still be provided with the old lib (and old .pc files too)
until such times as everything is updated. I would presume the name
mangling would allow for this to work OK with some clever tricks here
and there... (correctly me if I'm wrong)
Yes, I think that's the way to go.
Post by Colin Guthrie
This would surely be the nicest way to handle things during any
transition phase and could be turned off with a configure switch?
What are we trying to solve here? This is the job of the distro, it is
what it is there for. The distro either leaves the old lib around as
long as needed, or it re-compiles the users to use the new one.

Please do not mix code (upstream) and system composition
(distribution) too much here. It's all really the same model as an
SONAME bump, something that happens every day.

Thanks,
Kay
Colin Guthrie
2014-01-17 09:28:21 UTC
Permalink
Hi,

As far as I understand things, the goal is to be API compatible in terms
of function calls, but change the name of the pc files which is an API
break. Is this a correct summary? (if not then some of my comments below
don't work :D)
Post by Kay Sievers
On Fri, Jan 17, 2014 at 4:06 AM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
So there's "binary" compatibility, and "source" compatibility.
It would be nice if we could do those changes without
a) requiring recompilation ("binary")
b) requiring editing build scripts in dependent packages ("source").
For b, keeping around a .pc file which points to the *new* library
- Libs: -L${libdir} -lsystemd-login
+ Libs: -L${libdir} -lsystemd
On our side it's a tiny effort, and avoid a major PITA for distributions.
No, it will clash with the files from the old lib package. We should
not do that, if we no longer provide the same lib.
I guess Fedora do things differently, but we ship pc files in the -devel
package, so there would be no clashes with the old lib package for us...
This would be very useful.
Post by Kay Sievers
Post by Zbigniew Jędrzejewski-Szmek
For a, a compatibility symlink (e.g. libsystemd-login.so.0 -> libsystemd.so.0)
can be provided. I'm attaching a POC patch which moves the symbol exports
so that programs compiled against libsystemd-login will continue working.
The symlink is not created, this part must be done by hand.
I think that if we ever decide to futher merge libraries, those
would be the steps to take.
Same here, it creates clashes with the old files and is not strictly
what it pretends to be with the symlink name.
If said symlink is binary compatible, you could just ship an updated
version of that package. Sure it's a bit of a lie in that it's not a
real lib but I'd be OK with that personally (esp as it has to be done by
hand). If not then a stub lib rather than symlink wouldn't be lying so
is still OK as a plan if compatibility is desirable.
Post by Kay Sievers
Post by Zbigniew Jędrzejewski-Szmek
Post by Colin Guthrie
Could we not provide a libsystemd-daemon.so.0 that is just a stub and
links to libsystemd.so.X and just calls the functions therein? That way
the API could still be provided with the old lib (and old .pc files too)
until such times as everything is updated. I would presume the name
mangling would allow for this to work OK with some clever tricks here
and there... (correctly me if I'm wrong)
Yes, I think that's the way to go.
Post by Colin Guthrie
This would surely be the nicest way to handle things during any
transition phase and could be turned off with a configure switch?
What are we trying to solve here? This is the job of the distro, it is
what it is there for. The distro either leaves the old lib around as
long as needed, or it re-compiles the users to use the new one.
Please do not mix code (upstream) and system composition
(distribution) too much here. It's all really the same model as an
SONAME bump, something that happens every day.
Well you're also forcing "code" work onto "system composition" people as
they actively need patch things when we could provide an easy mechanism
for them to avoid this. This is different to an SONAME bump which
generally doesn't change the name of the .pc file and will often be fine
with a rebuild without any code modification.

As a disro maintainer, I'd be happy enough to ship a new systemd then
rebuild needed packages accordingly. What I'd be less happy about is the
API change that means my configure scripts don't work any longer and I
have to push patches into the consumer packages. There is no real need
for compat libs here, just compat .pc files. So from a distro
perspective I'd be happy with just that.


Perhaps you'd argue that such compat .pc files should just be shipped in
the distro's systemd package and not upstream? What I'm a little
confused about is that RHEL is going to be shipping systemd 207 or 208
and these "old" .pc names will be kinda embedded for quite some time.
Therefore consumer upstreams will be under pressure to keep the old
names in their configure scripts for a good number of years. If we
change them then we're forcing them to do an if/else structure in their
configures to check for both which is a little nasty. Surely shipping
compat .pc files just makes life easier for all concerned until there is
the need for a "real" API break?


Forgive me if I've misunderstood some other details of the change.

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/
Kay Sievers
2014-01-17 09:42:01 UTC
Permalink
Post by Colin Guthrie
As far as I understand things, the goal is to be API compatible in terms
of function calls, but change the name of the pc files which is an API
break. Is this a correct summary? (if not then some of my comments below
don't work :D)
Post by Kay Sievers
On Fri, Jan 17, 2014 at 4:06 AM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
So there's "binary" compatibility, and "source" compatibility.
It would be nice if we could do those changes without
a) requiring recompilation ("binary")
b) requiring editing build scripts in dependent packages ("source").
For b, keeping around a .pc file which points to the *new* library
- Libs: -L${libdir} -lsystemd-login
+ Libs: -L${libdir} -lsystemd
On our side it's a tiny effort, and avoid a major PITA for distributions.
No, it will clash with the files from the old lib package. We should
not do that, if we no longer provide the same lib.
I guess Fedora do things differently, but we ship pc files in the -devel
package, so there would be no clashes with the old lib package for us...
This would be very useful.
The header will not change, the new lib will install them too. So your
old -devel package cannot be installed in parallel.
Post by Colin Guthrie
Post by Kay Sievers
Post by Zbigniew Jędrzejewski-Szmek
For a, a compatibility symlink (e.g. libsystemd-login.so.0 -> libsystemd.so.0)
can be provided. I'm attaching a POC patch which moves the symbol exports
so that programs compiled against libsystemd-login will continue working.
The symlink is not created, this part must be done by hand.
I think that if we ever decide to futher merge libraries, those
would be the steps to take.
Same here, it creates clashes with the old files and is not strictly
what it pretends to be with the symlink name.
If said symlink is binary compatible, you could just ship an updated
version of that package. Sure it's a bit of a lie in that it's not a
real lib but I'd be OK with that personally (esp as it has to be done by
hand). If not then a stub lib rather than symlink wouldn't be lying so
is still OK as a plan if compatibility is desirable.
No, it's not ok to rely on such magic. The SONAME is not the same, and
such hacks do not belong there.
Post by Colin Guthrie
Post by Kay Sievers
Post by Zbigniew Jędrzejewski-Szmek
Post by Colin Guthrie
Could we not provide a libsystemd-daemon.so.0 that is just a stub and
links to libsystemd.so.X and just calls the functions therein? That way
the API could still be provided with the old lib (and old .pc files too)
until such times as everything is updated. I would presume the name
mangling would allow for this to work OK with some clever tricks here
and there... (correctly me if I'm wrong)
Yes, I think that's the way to go.
Post by Colin Guthrie
This would surely be the nicest way to handle things during any
transition phase and could be turned off with a configure switch?
What are we trying to solve here? This is the job of the distro, it is
what it is there for. The distro either leaves the old lib around as
long as needed, or it re-compiles the users to use the new one.
Please do not mix code (upstream) and system composition
(distribution) too much here. It's all really the same model as an
SONAME bump, something that happens every day.
Well you're also forcing "code" work onto "system composition" people as
they actively need patch things when we could provide an easy mechanism
for them to avoid this. This is different to an SONAME bump which
generally doesn't change the name of the .pc file and will often be fine
with a rebuild without any code modification.
As a disro maintainer, I'd be happy enough to ship a new systemd then
rebuild needed packages accordingly. What I'd be less happy about is the
API change that means my configure scripts don't work any longer and I
have to push patches into the consumer packages. There is no real need
for compat libs here, just compat .pc files. So from a distro
perspective I'd be happy with just that.
It's just one "echo" and you have that file if you need it.
Post by Colin Guthrie
Perhaps you'd argue that such compat .pc files should just be shipped in
the distro's systemd package and not upstream? What I'm a little
confused about is that RHEL is going to be shipping systemd 207 or 208
and these "old" .pc names will be kinda embedded for quite some time.
Therefore consumer upstreams will be under pressure to keep the old
names in their configure scripts for a good number of years. If we
change them then we're forcing them to do an if/else structure in their
configures to check for both which is a little nasty. Surely shipping
compat .pc files just makes life easier for all concerned until there is
the need for a "real" API break?
Forgive me if I've misunderstood some other details of the change.
We should just keep the libs as they are for a release, but provide
the functionality in the new lib under its correct name, and post
stuff over. After that's done we should see what's actually left to
cover, I doubt there is much. There is no need to solve that problem
at this very moment, we can just ship the old stuff for a short while.

This year will bring huge flag day compat breaks. We will drop all old
D-Bus support, we will require on a bleeding edge kernel, and so on.

I think mangling around a pc file name is absolutely nothing compared
what the next months will bring us. It's just not worth when you look
at the big picture what will happen soon.

Kay
Simon McVittie
2014-01-17 13:20:18 UTC
Permalink
Post by Kay Sievers
This year will bring huge flag day compat breaks. We will drop all old
D-Bus support, we will require on a bleeding edge kernel, and so on.
Flag-day compatibility breaks are a massive pain for distributions. The
more things need to be upgraded in lockstep, the harder it is -
particularly the kernel, since most distributions allow more than one
kernel to be installed at a time, and switching the running kernel needs
a reboot. Package dependency systems that were mainly designed for
libraries and restartable daemons can easily guarantee "linux >= 3.67 is
somewhere in the filesystem", but not "linux >= 3.67 was booted".

I can see that a flag day is sometimes unavoidable, but please do
consider it to be a significant cost. In particular, if your goal is for
systemd to be a universal part of a "standard" Linux stack, avoiding
flag-day upgrades whenever possible seems wise. I for one would like to
be able to assume systemd's technical advantages when writing other
software, but distributors who are uneasy about adopting systemd are not
going to be reassured by plans that will break their upgrades.

The kernel's policy is "don't break userspace" - isn't the init(1)
equivalent "don't break the rest of userspace"?

Regards,
S
Kay Sievers
2014-01-17 13:38:21 UTC
Permalink
On Fri, Jan 17, 2014 at 2:20 PM, Simon McVittie
Post by Simon McVittie
Post by Kay Sievers
This year will bring huge flag day compat breaks. We will drop all old
D-Bus support, we will require on a bleeding edge kernel, and so on.
Flag-day compatibility breaks are a massive pain for distributions. The
more things need to be upgraded in lockstep, the harder it is -
particularly the kernel, since most distributions allow more than one
kernel to be installed at a time, and switching the running kernel needs
a reboot. Package dependency systems that were mainly designed for
libraries and restartable daemons can easily guarantee "linux >= 3.67 is
somewhere in the filesystem", but not "linux >= 3.67 was booted".
In the kdbus case it's easy, there will be zero backward compat here.
Only higher-level users of D-Bus should continue to run without
noticing it. Systemd, tools in the base OS, and dbus-daemon will not.
Post by Simon McVittie
I can see that a flag day is sometimes unavoidable, but please do
consider it to be a significant cost. In particular, if your goal is for
systemd to be a universal part of a "standard" Linux stack, avoiding
flag-day upgrades whenever possible seems wise. I for one would like to
be able to assume systemd's technical advantages when writing other
software, but distributors who are uneasy about adopting systemd are not
going to be reassured by plans that will break their upgrades.
We don't break things for fun, but the dependency on kdbus will be
hard switch, and there will be no way back. It's unfortunate that this
need to happen, but it's worth the pain.

There are no alternatives really, as soon as we start using kdbus
features, port the journal to kdbus (logging cannot use dbus-daemon
because of cyclic deps) the possibility for dbus-daemon to run is
over, and with that there will be hard requirement on a recent kernel.
Post by Simon McVittie
The kernel's policy is "don't break userspace" - isn't the init(1)
equivalent "don't break the rest of userspace"?
No it isn't. We need to break things where progress in the base OS is
more worth than compatibility.

And working for years with enterprise systems, I call the kernel
maintainer's claim of not breaking userspace nothing but a dream. It's
a good goal, sure, but people just lie to themselves here with
statements like "forever" and such. The kernel/driver break interfaces
all the time. All that is reasonable stable is syscalls and old and
rather static interfaces like /proc.

People doing maintenance as their day job for many years just fix the
stuff and don't even tell anybody anymore. Mixing QA and development
makes not much sense, and it just doesn't work in reality how people
like to believe.

Kay
Lennart Poettering
2014-01-17 15:02:41 UTC
Permalink
Post by Simon McVittie
Post by Kay Sievers
This year will bring huge flag day compat breaks. We will drop all old
D-Bus support, we will require on a bleeding edge kernel, and so on.
Flag-day compatibility breaks are a massive pain for
distributions. The
Note that it is only some distributions which have a problem with
distro-wide changes like this. In Fedoraland it is a lot more common to
patch things through the entire distribution or rebuild all users of a
library on upgrade.

I certainly do understand that Debian does thigns differently here though.
Post by Simon McVittie
The kernel's policy is "don't break userspace" - isn't the init(1)
equivalent "don't break the rest of userspace"?
Well, see the "-lrt" libc transition. I am not sure we should be held to
higher standards there than libc...

Lennart
--
Lennart Poettering, Red Hat
Zbigniew Jędrzejewski-Szmek
2014-01-17 14:13:24 UTC
Permalink
Post by Kay Sievers
On Fri, Jan 17, 2014 at 4:06 AM, Zbigniew Jędrzejewski-Szmek
Post by Zbigniew Jędrzejewski-Szmek
So there's "binary" compatibility, and "source" compatibility.
It would be nice if we could do those changes without
a) requiring recompilation ("binary")
b) requiring editing build scripts in dependent packages ("source").
For b, keeping around a .pc file which points to the *new* library
- Libs: -L${libdir} -lsystemd-login
+ Libs: -L${libdir} -lsystemd
On our side it's a tiny effort, and avoid a major PITA for distributions.
No, it will clash with the files from the old lib package. We should
not do that, if we no longer provide the same lib.
There's nothing to clash with. Installing two versions of systemd
does not make sense, so we replace one containing the old .pc file,
with a new one, containing a different .pc file. There's no rule
that says that the .pc file must correspond one-to-one to a library.
Irrespective of whether there's a compat libsystemd-login.so in the
system, we want new binaries to link to libsystemd.so.

(Also, note that unless we marge all libraries, including -daemon,
so that there are no libraries sharing the name and so version
between systemd-old and systemd-after-the-merge, it won't be
possible to install even the libraries in parallel, because
e.g. /usr/lib/libsystemd-daemon.so.0 can't point in both directions.)
Post by Kay Sievers
Post by Zbigniew Jędrzejewski-Szmek
For a, a compatibility symlink (e.g. libsystemd-login.so.0 -> libsystemd.so.0)
can be provided. I'm attaching a POC patch which moves the symbol exports
so that programs compiled against libsystemd-login will continue working.
The symlink is not created, this part must be done by hand.
I think that if we ever decide to futher merge libraries, those
would be the steps to take.
Same here, it creates clashes with the old files and is not strictly
what it pretends to be with the symlink name.
OK, I buy the argument that this is a lot of magic. Downthread you
suggest, iiuc, to simply install libsystemd-login.so.0 containing a copy
of the code. This should work too and is very easy to implement.
Post by Kay Sievers
Post by Zbigniew Jędrzejewski-Szmek
Post by Colin Guthrie
Could we not provide a libsystemd-daemon.so.0 that is just a stub and
links to libsystemd.so.X and just calls the functions therein? That way
the API could still be provided with the old lib (and old .pc files too)
until such times as everything is updated. I would presume the name
mangling would allow for this to work OK with some clever tricks here
and there... (correctly me if I'm wrong)
Yes, I think that's the way to go.
Post by Colin Guthrie
This would surely be the nicest way to handle things during any
transition phase and could be turned off with a configure switch?
What are we trying to solve here? This is the job of the distro, it is
what it is there for. The distro either leaves the old lib around as
long as needed, or it re-compiles the users to use the new one.
Right now I can switch between systemd-208.rpm and systemd-209-git.rpm
without touching anything else. This is great for the user, and also
great for development. systemd is not really a project to be used
standalone by the user, it only has meaning when it is strongly
supported by other packages. We are nicely positioned in the middle of
everything, with our tentacles reaching into many distributions, so we
can prepare for the change and do it a way that avoid the flag day as
much as possible.

Zbyszek
Lennart Poettering
2014-01-17 14:45:03 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
So there's "binary" compatibility, and "source" compatibility.
It would be nice if we could do those changes without
a) requiring recompilation ("binary")
b) requiring editing build scripts in dependent packages ("source").
For b, keeping around a .pc file which points to the *new* library
- Libs: -L${libdir} -lsystemd-login
+ Libs: -L${libdir} -lsystemd
On our side it's a tiny effort, and avoid a major PITA for distributions.
For a, a compatibility symlink (e.g. libsystemd-login.so.0 -> libsystemd.so.0)
can be provided. I'm attaching a POC patch which moves the symbol exports
so that programs compiled against libsystemd-login will continue working.
The symlink is not created, this part must be done by hand.
I think that if we ever decide to futher merge libraries, those
would be the steps to take.
So here's my opinion on all of this:

First let me say that I am pretty strongly of the belief that API+ABI
breaks are something that distros have to deal with, it's one of the
primary reasons distros exist, so that they can deal with things like
this across the whole system. For example, recently glibc reorganized
"-lrt", and if they can do that, we certainly can do this too.

That said, while I believe that distros must be prepared to deal with
this, I think we can certainly help to make this easy for them, and make
the transition gradual rather than abrupt. However, for us upstream a
couple of things matter:

a) I don't want legacy/dead code in our upstream repo that we don't use
and hence test regularly. Thus I don't think it is an option to
simply keep two copies of everything in our repo, once for the old
and once for the new library.

b) The symbols after they have moved must carry a new, correct symbol
version, it's not an option to just move the library they are defined
in.

c) Manual symblinks between libraries are not an option I think, this
will break too easily, and will likely confuse tools like ldconfig...

d) Compatibility for the old library names and versions must be
isolated in the source tree, and it must be clear that we can remove this
easily within a year or so.

So, here's what I'd propose to maintain compatibility in both API and
ABI for a year or so:

1) Merge the libraries now. Give everything new symbol versions.

2) Expose the sd-bus/sd-event/sd-memfd/ symbols only if --enable-kdbus
is specified. People who enable this will hence get a different API
for this library than others! This is OK I think, by specifying
--enable-kdbus users basically declare that they know that there are
no API/ABI guarantees.

3) The new library will ship one .pc file only.

4) In a new subdirectory src/compat-libs/ (or something like that) we
will provide compat stubs that will build libraries (for ABI compat)
and pc files (for API compat) that redirect to
the new versions. This stuff should be optional though, and only be
enabled if --enable-compat-libs is specified, and the README should
name a date when this will be removed.

Now, the way I'd propose the stub libs of item #4 to be implemented is
via a combination of ".symver" asm magic, and the "ifunc" function
attribute. With a script we'd first generate for every old symbol code
like the following:

void new_sd_id128_from_string(void);
__asm__(".symver new_sd_id128_from_string,***@LIBSYSTEMD_209");

This would define a new symbol new_sd_id128_from_string which refers to
the specific version of the function from thew new library. Note that we
don't care for the right function signature, we only care for the naked
symbol name, that's all.

Then, we'd use ifunc to define a local function with the right name,
that just maps to the new implementation:

static void (*resolve_sd_id128_from_string (void)) (void) {
return new_sd_id128_from_string;
}
void sd_id128_from_string(void) __attribute__((ifunc("resolve_sd_id128_from_string")));

This newly defined function would then be assigned the right old version
with the ".sym" file, as before.

(Note that ideally we'd use the "weakref" gcc extension for this, but
that can only be used to define static aliases, and we need to export
this here, so this doesn't work. The ifunc trick is a work-around for
this limitation that should behave as close to this as possible, and
expose optimized performance, since ifunc is only evaluated once.)

Given that we don't care for the functions ignatures here it should be
trivial to write a script that generates this for all functions from the
old .sym files.

The symbols exposed should probably also carry the "deprecated" gcc
attribute so that people linking against them get a clear explanation
what to do and how to update to the new libs. Unfortunately .pc files
provide no support for encoding whether a lib is obsoelte, but we
should at least update the description string of the old .pc files to
declare them obsolete.

Yay for compiler magic!

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2014-01-17 14:58:07 UTC
Permalink
Post by Lennart Poettering
b) The symbols after they have moved must carry a new, correct symbol
version, it's not an option to just move the library they are defined
in.
To explain this: we must provide compatibility for processes that end up
linking against both the old and the new library. We must make sure that
tis doesn't result in symbol clashes, which means the symbols need to
carry different version numbers.

Lennart
--
Lennart Poettering, Red Hat
Zbigniew Jędrzejewski-Szmek
2014-01-17 16:41:26 UTC
Permalink
Post by Lennart Poettering
Post by Zbigniew Jędrzejewski-Szmek
So there's "binary" compatibility, and "source" compatibility.
It would be nice if we could do those changes without
a) requiring recompilation ("binary")
b) requiring editing build scripts in dependent packages ("source").
For b, keeping around a .pc file which points to the *new* library
- Libs: -L${libdir} -lsystemd-login
+ Libs: -L${libdir} -lsystemd
On our side it's a tiny effort, and avoid a major PITA for distributions.
For a, a compatibility symlink (e.g. libsystemd-login.so.0 -> libsystemd.so.0)
can be provided. I'm attaching a POC patch which moves the symbol exports
so that programs compiled against libsystemd-login will continue working.
The symlink is not created, this part must be done by hand.
I think that if we ever decide to futher merge libraries, those
would be the steps to take.
First let me say that I am pretty strongly of the belief that API+ABI
breaks are something that distros have to deal with, it's one of the
primary reasons distros exist, so that they can deal with things like
this across the whole system. For example, recently glibc reorganized
"-lrt", and if they can do that, we certainly can do this too.
That said, while I believe that distros must be prepared to deal with
this, I think we can certainly help to make this easy for them, and make
the transition gradual rather than abrupt. However, for us upstream a
a) I don't want legacy/dead code in our upstream repo that we don't use
and hence test regularly. Thus I don't think it is an option to
simply keep two copies of everything in our repo, once for the old
and once for the new library.
b) The symbols after they have moved must carry a new, correct symbol
version, it's not an option to just move the library they are defined
in.
c) Manual symblinks between libraries are not an option I think, this
will break too easily, and will likely confuse tools like ldconfig...
d) Compatibility for the old library names and versions must be
isolated in the source tree, and it must be clear that we can remove this
easily within a year or so.
OK.
Post by Lennart Poettering
So, here's what I'd propose to maintain compatibility in both API and
1) Merge the libraries now. Give everything new symbol versions.
2) Expose the sd-bus/sd-event/sd-memfd/ symbols only if --enable-kdbus
is specified. People who enable this will hence get a different API
for this library than others! This is OK I think, by specifying
--enable-kdbus users basically declare that they know that there are
no API/ABI guarantees.
3) The new library will ship one .pc file only.
4) In a new subdirectory src/compat-libs/ (or something like that) we
will provide compat stubs that will build libraries (for ABI compat)
and pc files (for API compat) that redirect to
the new versions. This stuff should be optional though, and only be
enabled if --enable-compat-libs is specified, and the README should
name a date when this will be removed.
OK.
Post by Lennart Poettering
Now, the way I'd propose the stub libs of item #4 to be implemented is
via a combination of ".symver" asm magic, and the "ifunc" function
attribute. With a script we'd first generate for every old symbol code
void new_sd_id128_from_string(void);
This would define a new symbol new_sd_id128_from_string which refers to
the specific version of the function from thew new library. Note that we
don't care for the right function signature, we only care for the naked
symbol name, that's all.
Then, we'd use ifunc to define a local function with the right name,
static void (*resolve_sd_id128_from_string (void)) (void) {
return new_sd_id128_from_string;
}
void sd_id128_from_string(void) __attribute__((ifunc("resolve_sd_id128_from_string")));
This newly defined function would then be assigned the right old version
with the ".sym" file, as before.
This sounds like a good plan.

Zbyszek
Zbigniew Jędrzejewski-Szmek
2014-01-19 13:51:52 UTC
Permalink
So, I prepared a test patch. This all doesn't seem to be too ugly generally,
although the warning generation in patch 2 is a bit.

Comments?

A compatibility libsystemd-login library is created which uses
.symver and ifunc magic proposed by Lennart to make programs linked
to the old library name continue to work seamlessly.

Unfortunately the bfd linker crashes:
https://sourceware.org/bugzilla/show_bug.cgi?id=16467
As a work-around, gold can be used:
LDFLAGS=-Wl,-fuse-ld=gold

This also doesn't work with LLVM:
http://llvm.org/bugs/show_bug.cgi?id=11897
---

.gitignore | 1 +
Makefile.am | 125 +++++++++++++++++++----------------------
src/libsystemd/libsystemd.sym | 61 ++++++++++++++++++++
src/login/libsystemd-login.sym | 7 ---
4 files changed, 120 insertions(+), 74 deletions(-)

diff --git a/.gitignore b/.gitignore
index 115ec52..de49d2b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -33,6 +33,7 @@
/hostnamectl
/install-tree
/journalctl
+/libsystemd-login.c
/libtool
/localectl
/loginctl
diff --git a/Makefile.am b/Makefile.am
index b989fdd..9929e24 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -44,7 +44,7 @@ LIBGUDEV_REVISION=3
LIBGUDEV_AGE=1

LIBSYSTEMD_LOGIN_CURRENT=9
-LIBSYSTEMD_LOGIN_REVISION=1
+LIBSYSTEMD_LOGIN_REVISION=2
LIBSYSTEMD_LOGIN_AGE=9

LIBSYSTEMD_DAEMON_CURRENT=0
@@ -1802,14 +1802,7 @@ systemctl_LDADD = \
libsystemd-units.la \
libsystemd-label.la \
libsystemd-internal.la \
- libsystemd-logs.la
-
-if ENABLE_LOGIND
-systemctl_LDADD += \
- libsystemd-login-internal.la
-endif
-
-systemctl_LDADD += \
+ libsystemd-logs.la \
libsystemd-journal-internal.la \
libsystemd-id128-internal.la \
libsystemd-daemon-internal.la \
@@ -2036,7 +2029,11 @@ libsystemd_la_SOURCES = \
src/libsystemd/rtnl-util.h \
src/libsystemd/rtnl-util.c \
src/libsystemd/sd-resolve.c \
- src/libsystemd/resolve-util.h
+ src/libsystemd/resolve-util.h \
+ src/login/sd-login.c \
+ src/systemd/sd-login.h \
+ src/login/login-shared.c \
+ src/login/login-shared.h

nodist_libsystemd_la_SOURCES = \
src/libsystemd/bus-error-mapping.c
@@ -3267,11 +3264,6 @@ libsystemd_journal_core_la_LIBADD = \
libsystemd-id128-internal.la \
libsystemd-shared.la

-if ENABLE_LOGIND
-libsystemd_journal_core_la_LIBADD += \
- libsystemd-login-internal.la
-endif
-
if HAVE_ACL
libsystemd_journal_core_la_LIBADD += \
libsystemd-acl.la
@@ -3469,12 +3461,8 @@ systemd_coredump_SOURCES = \
systemd_coredump_LDADD = \
libsystemd-journal-internal.la \
libsystemd-label.la \
- libsystemd-shared.la
-
-if ENABLE_LOGIND
-systemd_coredump_LDADD += \
- libsystemd-login-internal.la
-endif
+ libsystemd-shared.la \
+ libsystemd-internal.la

rootlibexec_PROGRAMS += \
systemd-coredump
@@ -4235,14 +4223,14 @@ test_login_SOURCES = \
src/login/test-login.c

test_login_LDADD = \
- libsystemd-login-internal.la \
+ libsystemd-internal.la \
libsystemd-shared.la

test_login_shared_SOURCES = \
src/login/test-login-shared.c

test_login_shared_LDADD = \
- libsystemd-login-internal.la \
+ libsystemd-internal.la \
libsystemd-shared.la

test_inhibit_SOURCES = \
@@ -4268,29 +4256,6 @@ tests += \
test-login-tables \
test-login-shared

-libsystemd_login_la_SOURCES = \
- src/login/libsystemd-login.sym \
- src/login/sd-login.c \
- src/systemd/sd-login.h \
- src/login/login-shared.c \
- src/login/login-shared.h
-
-libsystemd_login_la_CFLAGS = \
- $(AM_CFLAGS) \
- -fvisibility=hidden
-
-libsystemd_login_la_LDFLAGS = \
- $(AM_LDFLAGS) \
- -version-info $(LIBSYSTEMD_LOGIN_CURRENT):$(LIBSYSTEMD_LOGIN_REVISION):$(LIBSYSTEMD_LOGIN_AGE) \
- -Wl,--version-script=$(top_srcdir)/src/login/libsystemd-login.sym
-
-libsystemd_login_la_LIBADD = \
- libsystemd-daemon-internal.la \
- libsystemd-shared.la
-
-libsystemd_login_internal_la_SOURCES = \
- $(libsystemd_login_la_SOURCES)
-
if HAVE_PAM
pam_systemd_la_SOURCES = \
src/login/pam-module.c
@@ -4323,16 +4288,6 @@ dist_pamconf_DATA = \
src/login/systemd-user
endif

-# move lib from $(libdir) to $(rootlibdir) and update devel link, if needed
-libsystemd-login-install-hook:
- libname=libsystemd-login.so && $(move-to-rootlibdir)
-
-libsystemd-login-uninstall-hook:
- rm -f $(DESTDIR)$(rootlibdir)/libsystemd-login.so*
-
-INSTALL_EXEC_HOOKS += libsystemd-login-install-hook
-UNINSTALL_EXEC_HOOKS += libsystemd-login-uninstall-hook
-
nodist_systemunit_DATA += \
units/systemd-logind.service \
units/systemd-user-sessions.service
@@ -4353,15 +4308,6 @@ dist_pkgsysconf_DATA += \
pkginclude_HEADERS += \
src/systemd/sd-login.h

-lib_LTLIBRARIES += \
- libsystemd-login.la
-
-noinst_LTLIBRARIES += \
- libsystemd-login-internal.la
-
-pkgconfiglib_DATA += \
- src/login/libsystemd-login.pc
-
polkitpolicy_files += \
src/login/org.freedesktop.login1.policy

@@ -4529,7 +4475,7 @@ login_la_LDFLAGS = \
login_la_LIBADD = \
$(PYTHON_DEVEL_LIBS) \
libsystemd-journal.la \
- libsystemd-login.la \
+ libsystemd.la \
libsystemd-daemon-internal.la \
libsystemd-shared.la

@@ -4574,6 +4520,50 @@ clean-python:
-rm -f _daemon.la id128.la _journal.la login.la _reader.la

# ------------------------------------------------------------------------------
+define generate-fake-lib
+ $(AM_V_at)$(MKDIR_P) $(dir $@)
+ $(AM_V_GEN)sed -r -n 's/^ +(sd_.*);/void new_\1(void);\n__asm__(".symver new_\1,\***@LIBSYSTEMD_209");\nstatic void (*resolve_\1(void)) (void) {\n\treturn new_\1;\n}\nvoid \1(void) __attribute__((ifunc("resolve_\1")));\n/p' <$< >$@
+endef
+
+libsystemd_login_la_SOURCES = \
+ libsystemd-login.c \
+ src/login/libsystemd-login.sym
+
+libsystemd_login_la_CFLAGS = \
+ $(AM_CFLAGS) \
+ -fvisibility=default
+
+libsystemd_login_la_LDFLAGS = \
+ $(AM_LDFLAGS) \
+ -version-info $(LIBSYSTEMD_LOGIN_CURRENT):$(LIBSYSTEMD_LOGIN_REVISION):$(LIBSYSTEMD_LOGIN_AGE) \
+ -Wl,--version-script=$(top_srcdir)/src/login/libsystemd-login.sym
+
+libsystemd_login_la_LIBADD = \
+ libsystemd.la
+
+BUILT_SOURCES += \
+ libsystemd-login.c
+
+libsystemd-login.c: src/login/libsystemd-login.sym
+ $(generate-fake-lib)
+
+lib_LTLIBRARIES += \
+ libsystemd-login.la
+
+pkgconfiglib_DATA += \
+ src/login/libsystemd-login.pc
+
+# move lib from $(libdir) to $(rootlibdir) and update devel link, if needed
+libsystemd-login-install-hook:
+ libname=libsystemd-login.so && $(move-to-rootlibdir)
+
+libsystemd-login-uninstall-hook:
+ rm -f $(DESTDIR)$(rootlibdir)/libsystemd-login.so*
+
+INSTALL_EXEC_HOOKS += libsystemd-login-install-hook
+UNINSTALL_EXEC_HOOKS += libsystemd-login-uninstall-hook
+
+# ------------------------------------------------------------------------------
substitutions = \
'|rootlibexecdir=$(rootlibexecdir)|' \
'|rootbindir=$(rootbindir)|' \
@@ -4989,7 +4979,8 @@ endef
test-libsystemd-sym.c: \
src/libsystemd/libsystemd.sym \
src/systemd/sd-bus.h \
- src/systemd/sd-utf8.h
+ src/systemd/sd-utf8.h \
+ src/systemd/sd-login.h
$(generate-sym-test)

test-libsystemd-daemon-sym.c: \
diff --git a/src/libsystemd/libsystemd.sym b/src/libsystemd/libsystemd.sym
index cda10ea..9bbe9bc 100644
--- a/src/libsystemd/libsystemd.sym
+++ b/src/libsystemd/libsystemd.sym
@@ -9,6 +9,67 @@

LIBSYSTEMD_209 {
global:
+
+ /* originally LIBSYSTEMD_LOGIN_31 */
+ sd_get_seats;
+ sd_get_sessions;
+ sd_get_uids;
+ sd_login_monitor_flush;
+ sd_login_monitor_get_fd;
+ sd_login_monitor_new;
+ sd_login_monitor_unref;
+ sd_pid_get_owner_uid;
+ sd_pid_get_session;
+ sd_seat_can_multi_session;
+ sd_seat_get_active;
+ sd_seat_get_sessions;
+ sd_session_get_seat;
+ sd_session_get_uid;
+ sd_session_is_active;
+ sd_uid_get_seats;
+ sd_uid_get_sessions;
+ sd_uid_get_state;
+ sd_uid_is_on_seat;
+
+ /* originally LIBSYSTEMD_LOGIN_38 */
+ sd_pid_get_unit;
+ sd_session_get_service;
+
+ /* originally LIBSYSTEMD_LOGIN_43 */
+ sd_session_get_type;
+ sd_session_get_class;
+ sd_session_get_display;
+
+ /* originally LIBSYSTEMD_LOGIN_186 */
+ sd_session_get_state;
+ sd_seat_can_tty;
+ sd_seat_can_graphical;
+
+ /* originally LIBSYSTEMD_LOGIN_198 */
+ sd_session_get_tty;
+
+ /* originally LIBSYSTEMD_LOGIN_201 */
+ sd_login_monitor_get_events;
+ sd_login_monitor_get_timeout;
+
+ /* originally LIBSYSTEMD_LOGIN_202 */
+ sd_pid_get_user_unit;
+ sd_pid_get_machine_name;
+
+ /* originally LIBSYSTEMD_LOGIN_203 */
+ sd_get_machine_names;
+
+ /* originally LIBSYSTEMD_LOGIN_205 */
+ sd_pid_get_slice;
+
+ /* originally LIBSYSTEMD_LOGIN_207 */
+ sd_session_get_vt;
+
+ /* new in LIBSYSTEMD_LOGIN_209 */
+ sd_session_is_remote;
+ sd_session_get_remote_user;
+ sd_session_get_remote_host;
+
/* Same order as in sd-bus.h should be used */

/* Connections */
diff --git a/src/login/libsystemd-login.sym b/src/login/libsystemd-login.sym
index 1d33982..54aa91c 100644
--- a/src/login/libsystemd-login.sym
+++ b/src/login/libsystemd-login.sym
@@ -85,10 +85,3 @@ LIBSYSTEMD_LOGIN_207 {
global:
sd_session_get_vt;
} LIBSYSTEMD_LOGIN_205;
-
-LIBSYSTEMD_LOGIN_209 {
-global:
- sd_session_is_remote;
- sd_session_get_remote_user;
- sd_session_get_remote_host;
-} LIBSYSTEMD_LOGIN_207;
--
1.8.1.rc0.194.gaf2e3a9
Zbigniew Jędrzejewski-Szmek
2014-01-19 13:51:53 UTC
Permalink
Compat stuff is moved to src/compat-libs/.
Warnings are issued when programs with the deprecated library.
---
Makefile.am | 21 ++++----
configure.ac | 12 +++++
src/compat-libs/.gitignore | 1 +
src/compat-libs/libsystemd-login.pc.in | 18 +++++++
src/compat-libs/libsystemd-login.sym | 87 ++++++++++++++++++++++++++++++++++
src/compat-libs/linkwarning.h | 34 +++++++++++++
src/login/.gitignore | 1 -
src/login/libsystemd-login.pc.in | 18 -------
src/login/libsystemd-login.sym | 87 ----------------------------------
9 files changed, 165 insertions(+), 114 deletions(-)
create mode 100644 src/compat-libs/.gitignore
create mode 100644 src/compat-libs/libsystemd-login.pc.in
create mode 100644 src/compat-libs/libsystemd-login.sym
create mode 100644 src/compat-libs/linkwarning.h
delete mode 100644 src/login/libsystemd-login.pc.in
delete mode 100644 src/login/libsystemd-login.sym

diff --git a/Makefile.am b/Makefile.am
index 9929e24..f6bdc6d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4357,7 +4357,7 @@ polkitpolicy_in_files += \

EXTRA_DIST += \
src/login/logind-gperf.gperf \
- src/login/libsystemd-login.pc.in \
+ src/compat-libs/libsystemd-login.pc.in \
src/login/71-seat.rules.in \
src/login/73-seat-late.rules.in \
units/systemd-logind.service.in \
@@ -4520,23 +4520,26 @@ clean-python:
-rm -f _daemon.la id128.la _journal.la login.la _reader.la

# ------------------------------------------------------------------------------
+if ENABLE_COMPAT_LIBS
+
define generate-fake-lib
$(AM_V_at)$(MKDIR_P) $(dir $@)
- $(AM_V_GEN)sed -r -n 's/^ +(sd_.*);/void new_\1(void);\n__asm__(".symver new_\1,\***@LIBSYSTEMD_209");\nstatic void (*resolve_\1(void)) (void) {\n\treturn new_\1;\n}\nvoid \1(void) __attribute__((ifunc("resolve_\1")));\n/p' <$< >$@
+ $(AM_V_GEN)sed -r -n 's/^ +(sd_.*);/void new_\1(void);\n__asm__(".symver new_\1,\***@LIBSYSTEMD_209");\nstatic void (*resolve_\1(void)) (void) {\n\treturn new_\1;\n}\nvoid \1(void) __attribute__((ifunc("resolve_\1")));\nobsolete_lib(\1,$(notdir $(basename $<)));\n/p' <$< >$@
endef

libsystemd_login_la_SOURCES = \
libsystemd-login.c \
- src/login/libsystemd-login.sym
+ src/compat-libs/libsystemd-login.sym

libsystemd_login_la_CFLAGS = \
$(AM_CFLAGS) \
- -fvisibility=default
+ -fvisibility=default \
+ -imacros $(top_srcdir)/src/compat-libs/linkwarning.h

libsystemd_login_la_LDFLAGS = \
$(AM_LDFLAGS) \
-version-info $(LIBSYSTEMD_LOGIN_CURRENT):$(LIBSYSTEMD_LOGIN_REVISION):$(LIBSYSTEMD_LOGIN_AGE) \
- -Wl,--version-script=$(top_srcdir)/src/login/libsystemd-login.sym
+ -Wl,--version-script=$(top_srcdir)/src/compat-libs/libsystemd-login.sym

libsystemd_login_la_LIBADD = \
libsystemd.la
@@ -4544,14 +4547,14 @@ libsystemd_login_la_LIBADD = \
BUILT_SOURCES += \
libsystemd-login.c

-libsystemd-login.c: src/login/libsystemd-login.sym
+libsystemd-login.c: src/compat-libs/libsystemd-login.sym
$(generate-fake-lib)

lib_LTLIBRARIES += \
libsystemd-login.la

pkgconfiglib_DATA += \
- src/login/libsystemd-login.pc
+ src/compat-libs/libsystemd-login.pc

# move lib from $(libdir) to $(rootlibdir) and update devel link, if needed
libsystemd-login-install-hook:
@@ -4563,6 +4566,8 @@ libsystemd-login-uninstall-hook:
INSTALL_EXEC_HOOKS += libsystemd-login-install-hook
UNINSTALL_EXEC_HOOKS += libsystemd-login-uninstall-hook

+endif
+
# ------------------------------------------------------------------------------
substitutions = \
'|rootlibexecdir=$(rootlibexecdir)|' \
@@ -4999,7 +5004,7 @@ test-libsystemd-journal-sym.c: \
$(generate-sym-test)

test-libsystemd-login-sym.c: \
- src/login/libsystemd-login.sym \
+ src/compat-libs/libsystemd-login.sym \
src/systemd/sd-login.h
$(generate-sym-test)

diff --git a/configure.ac b/configure.ac
index 939ba6d..ac723a5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -258,6 +258,17 @@ AS_IF([test "x$enable_dbus" != "xno"], [
AM_CONDITIONAL(HAVE_DBUS, [test "$have_dbus" = "yes"])

# ------------------------------------------------------------------------------
+have_compat_libs=no
+AC_ARG_ENABLE([compat_libs], AS_HELP_STRING([--enable-compat-libs],[Enable creation of compatibility libraries]),
+ [case "${enableval}" in
+ yes) have_compat_libs=yes ;;
+ no) have_compat_libs=no ;;
+ *) AC_MSG_ERROR(bad value ${enableval} for --enable-compat-libs) ;;
+ esac],
+ [have_compat_libs=no])
+AM_CONDITIONAL([ENABLE_COMPAT_LIBS], [test "$have_compat_libs" = "yes"])
+
+# ------------------------------------------------------------------------------
have_coverage=no
AC_ARG_ENABLE(coverage, AS_HELP_STRING([--enable-coverage], [enable test coverage]))
if test "x$enable_coverage" = "xyes" ; then
@@ -1116,6 +1127,7 @@ AC_MSG_RESULT([
test coverage: ${have_coverage}
Split /usr: ${enable_split_usr}
SysV compatibility: ${SYSTEM_SYSV_COMPAT}
+ compatibility libraries: ${have_compat_libs}

prefix: ${prefix}
rootprefix: ${with_rootprefix}
diff --git a/src/compat-libs/.gitignore b/src/compat-libs/.gitignore
new file mode 100644
index 0000000..0b8d106
--- /dev/null
+++ b/src/compat-libs/.gitignore
@@ -0,0 +1 @@
+/libsystemd-login.pc
diff --git a/src/compat-libs/libsystemd-login.pc.in b/src/compat-libs/libsystemd-login.pc.in
new file mode 100644
index 0000000..677f6b6
--- /dev/null
+++ b/src/compat-libs/libsystemd-login.pc.in
@@ -0,0 +1,18 @@
+# This file is part of systemd.
+#
+# systemd is free software; you can redistribute it and/or modify it
+# under the terms of the GNU Lesser General Public License as published by
+# the Free Software Foundation; either version 2.1 of the License, or
+# (at your option) any later version.
+
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name: systemd
+Description: systemd Login Utility Library deprecated compatibility library
+URL: @PACKAGE_URL@
+Version: @PACKAGE_VERSION@
+Libs: -L${libdir} -lsystemd
+Cflags: -I${includedir}
diff --git a/src/compat-libs/libsystemd-login.sym b/src/compat-libs/libsystemd-login.sym
new file mode 100644
index 0000000..54aa91c
--- /dev/null
+++ b/src/compat-libs/libsystemd-login.sym
@@ -0,0 +1,87 @@
+/***
+ This file is part of systemd.
+
+ systemd is free software; you can redistribute it and/or modify it
+ under the terms of the GNU Lesser General Public License as published by
+ the Free Software Foundation; either version 2.1 of the License, or
+ (at your option) any later version.
+***/
+
+/* Original symbols from systemd v31 */
+
+LIBSYSTEMD_LOGIN_31 {
+global:
+ sd_get_seats;
+ sd_get_sessions;
+ sd_get_uids;
+ sd_login_monitor_flush;
+ sd_login_monitor_get_fd;
+ sd_login_monitor_new;
+ sd_login_monitor_unref;
+ sd_pid_get_owner_uid;
+ sd_pid_get_session;
+ sd_seat_can_multi_session;
+ sd_seat_get_active;
+ sd_seat_get_sessions;
+ sd_session_get_seat;
+ sd_session_get_uid;
+ sd_session_is_active;
+ sd_uid_get_seats;
+ sd_uid_get_sessions;
+ sd_uid_get_state;
+ sd_uid_is_on_seat;
+local:
+ *;
+};
+
+LIBSYSTEMD_LOGIN_38 {
+global:
+ sd_pid_get_unit;
+ sd_session_get_service;
+} LIBSYSTEMD_LOGIN_31;
+
+LIBSYSTEMD_LOGIN_43 {
+global:
+ sd_session_get_type;
+ sd_session_get_class;
+ sd_session_get_display;
+} LIBSYSTEMD_LOGIN_38;
+
+LIBSYSTEMD_LOGIN_186 {
+global:
+ sd_session_get_state;
+ sd_seat_can_tty;
+ sd_seat_can_graphical;
+} LIBSYSTEMD_LOGIN_43;
+
+LIBSYSTEMD_LOGIN_198 {
+global:
+ sd_session_get_tty;
+} LIBSYSTEMD_LOGIN_186;
+
+LIBSYSTEMD_LOGIN_201 {
+global:
+ sd_login_monitor_get_events;
+ sd_login_monitor_get_timeout;
+} LIBSYSTEMD_LOGIN_198;
+
+LIBSYSTEMD_LOGIN_202 {
+global:
+ sd_pid_get_user_unit;
+ sd_pid_get_machine_name;
+} LIBSYSTEMD_LOGIN_201;
+
+LIBSYSTEMD_LOGIN_203 {
+global:
+ sd_get_machine_names;
+} LIBSYSTEMD_LOGIN_202;
+
+LIBSYSTEMD_LOGIN_205 {
+global:
+ sd_pid_get_slice;
+} LIBSYSTEMD_LOGIN_203;
+
+LIBSYSTEMD_LOGIN_207 {
+global:
+ sd_session_get_vt;
+} LIBSYSTEMD_LOGIN_205;
diff --git a/src/compat-libs/linkwarning.h b/src/compat-libs/linkwarning.h
new file mode 100644
index 0000000..1a412e9
--- /dev/null
+++ b/src/compat-libs/linkwarning.h
@@ -0,0 +1,34 @@
+/***
+ This file is part of systemd, but is heavily based on
+ glibc's libc-symbols.h.
+
+ Copyright (C) 1995-1998,2000-2006,2008,2009 Free Software Foundation, Inc
+
+ systemd is free software; you can redistribute it and/or modify it
+ under the terms of the GNU Lesser General Public License as published by
+ the Free Software Foundation; either version 2.1 of the License, or
+ (at your option) any later version.
+
+ systemd is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with systemd; If not, see <http://www.gnu.org/licenses/>.
+***/
+
+
+#define __make_section_unallocated(section_string) \
+ asm (".section " section_string "\n\t.previous");
+
+#define __sec_comment "\n#APP\n\t#"
+
+#define link_warning(symbol, msg) \
+ __make_section_unallocated (".gnu.warning." #symbol) \
+ static const char __evoke_link_warning_##symbol[] \
+ __attribute__ ((used, section (".gnu.warning." #symbol __sec_comment))) \
+ = msg
+
+#define obsolete_lib(name,lib) \
+ link_warning(name, #name " was moved to libsystemd. Do not use " #lib ".")
diff --git a/src/login/.gitignore b/src/login/.gitignore
index d3840c7..5c0b2ac 100644
--- a/src/login/.gitignore
+++ b/src/login/.gitignore
@@ -1,4 +1,3 @@
-/libsystemd-login.pc
/logind-gperf.c
/org.freedesktop.login1.policy
/71-seat.rules
diff --git a/src/login/libsystemd-login.pc.in b/src/login/libsystemd-login.pc.in
deleted file mode 100644
index 7b2a724..0000000
--- a/src/login/libsystemd-login.pc.in
+++ /dev/null
@@ -1,18 +0,0 @@
-# This file is part of systemd.
-#
-# systemd is free software; you can redistribute it and/or modify it
-# under the terms of the GNU Lesser General Public License as published by
-# the Free Software Foundation; either version 2.1 of the License, or
-# (at your option) any later version.
-
-prefix=@prefix@
-exec_prefix=@exec_prefix@
-libdir=@libdir@
-includedir=@includedir@
-
-Name: systemd
-Description: systemd Login Utility Library
-URL: @PACKAGE_URL@
-Version: @PACKAGE_VERSION@
-Libs: -L${libdir} -lsystemd-login
-Cflags: -I${includedir}
diff --git a/src/login/libsystemd-login.sym b/src/login/libsystemd-login.sym
deleted file mode 100644
index 54aa91c..0000000
--- a/src/login/libsystemd-login.sym
+++ /dev/null
@@ -1,87 +0,0 @@
-/***
- This file is part of systemd.
-
- systemd is free software; you can redistribute it and/or modify it
- under the terms of the GNU Lesser General Public License as published by
- the Free Software Foundation; either version 2.1 of the License, or
- (at your option) any later version.
-***/
-
-/* Original symbols from systemd v31 */
-
-LIBSYSTEMD_LOGIN_31 {
-global:
- sd_get_seats;
- sd_get_sessions;
- sd_get_uids;
- sd_login_monitor_flush;
- sd_login_monitor_get_fd;
- sd_login_monitor_new;
- sd_login_monitor_unref;
- sd_pid_get_owner_uid;
- sd_pid_get_session;
- sd_seat_can_multi_session;
- sd_seat_get_active;
- sd_seat_get_sessions;
- sd_session_get_seat;
- sd_session_get_uid;
- sd_session_is_active;
- sd_uid_get_seats;
- sd_uid_get_sessions;
- sd_uid_get_state;
- sd_uid_is_on_seat;
-local:
- *;
-};
-
-LIBSYSTEMD_LOGIN_38 {
-global:
- sd_pid_get_unit;
- sd_session_get_service;
-} LIBSYSTEMD_LOGIN_31;
-
-LIBSYSTEMD_LOGIN_43 {
-global:
- sd_session_get_type;
- sd_session_get_class;
- sd_session_get_display;
-} LIBSYSTEMD_LOGIN_38;
-
-LIBSYSTEMD_LOGIN_186 {
-global:
- sd_session_get_state;
- sd_seat_can_tty;
- sd_seat_can_graphical;
-} LIBSYSTEMD_LOGIN_43;
-
-LIBSYSTEMD_LOGIN_198 {
-global:
- sd_session_get_tty;
-} LIBSYSTEMD_LOGIN_186;
-
-LIBSYSTEMD_LOGIN_201 {
-global:
- sd_login_monitor_get_events;
- sd_login_monitor_get_timeout;
-} LIBSYSTEMD_LOGIN_198;
-
-LIBSYSTEMD_LOGIN_202 {
-global:
- sd_pid_get_user_unit;
- sd_pid_get_machine_name;
-} LIBSYSTEMD_LOGIN_201;
-
-LIBSYSTEMD_LOGIN_203 {
-global:
- sd_get_machine_names;
-} LIBSYSTEMD_LOGIN_202;
-
-LIBSYSTEMD_LOGIN_205 {
-global:
- sd_pid_get_slice;
-} LIBSYSTEMD_LOGIN_203;
-
-LIBSYSTEMD_LOGIN_207 {
-global:
- sd_session_get_vt;
-} LIBSYSTEMD_LOGIN_205;
--
1.8.1.rc0.194.gaf2e3a9
Lennart Poettering
2014-01-20 12:14:02 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
So, I prepared a test patch. This all doesn't seem to be too ugly generally,
although the warning generation in patch 2 is a bit.
Comments?
A compatibility libsystemd-login library is created which uses
.symver and ifunc magic proposed by Lennart to make programs linked
to the old library name continue to work seamlessly.
https://sourceware.org/bugzilla/show_bug.cgi?id=16467
LDFLAGS=-Wl,-fuse-ld=gold
http://llvm.org/bugs/show_bug.cgi?id=11897
Looks good to me. That bfd chokes on this is a bummer though... But as
long as the bfd fix is backportable it sounds totally OK to me to still
do this.

Lennart
--
Lennart Poettering, Red Hat
Zbigniew Jędrzejewski-Szmek
2014-01-20 16:42:39 UTC
Permalink
Post by Lennart Poettering
Post by Zbigniew Jędrzejewski-Szmek
So, I prepared a test patch. This all doesn't seem to be too ugly generally,
although the warning generation in patch 2 is a bit.
Comments?
A compatibility libsystemd-login library is created which uses
.symver and ifunc magic proposed by Lennart to make programs linked
to the old library name continue to work seamlessly.
https://sourceware.org/bugzilla/show_bug.cgi?id=16467
LDFLAGS=-Wl,-fuse-ld=gold
http://llvm.org/bugs/show_bug.cgi?id=11897
Looks good to me. That bfd chokes on this is a bummer though... But as
long as the bfd fix is backportable it sounds totally OK to me to still
do this.
The bfs fix is backportable, and was proposed for the stable branch too.

Anyway, I don't see why using gold would be bad.

Zbyszek
Lennart Poettering
2014-01-20 17:08:49 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
Post by Zbigniew Jędrzejewski-Szmek
So, I prepared a test patch. This all doesn't seem to be too ugly generally,
although the warning generation in patch 2 is a bit.
Comments?
A compatibility libsystemd-login library is created which uses
.symver and ifunc magic proposed by Lennart to make programs linked
to the old library name continue to work seamlessly.
https://sourceware.org/bugzilla/show_bug.cgi?id=16467
LDFLAGS=-Wl,-fuse-ld=gold
http://llvm.org/bugs/show_bug.cgi?id=11897
Looks good to me. That bfd chokes on this is a bummer though... But as
long as the bfd fix is backportable it sounds totally OK to me to still
do this.
The bfs fix is backportable, and was proposed for the stable branch too.
Anyway, I don't see why using gold would be bad.
Good question. I have no experience with gold, but it's commonly
available these days, right? maybe we should just default to gold anyway
after detection in configur.ac?

Lennart
--
Lennart Poettering, Red Hat
Simon McVittie
2014-01-20 17:47:48 UTC
Permalink
Post by Lennart Poettering
Post by Zbigniew Jędrzejewski-Szmek
Anyway, I don't see why using gold would be bad.
Good question. I have no experience with gold, but it's commonly
available these days, right?
"Sort of; hardware-dependent". It's better than it used to be (initially
x86-only); among the Debian architectures, it exists on the x86, ARM,
PowerPC and Sparc families, but not mips*, s390x, ia64 or various
unofficial ports. I don't know which one new architecture families tend
to bootstrap with.
Post by Lennart Poettering
maybe we should just default to gold anyway
after detection in configur.ac?
Choosing a default linker seems like a system-integration issue rather
than something individual upstreams should be doing. For a while, D-Bus
forced particular "hardening" compiler options if they existed (-fPIC,
etc.), but they were often broken on particular
architectures/toolchains, and we eventually came to the conclusion that
it's far easier for a distribution to do that sort of thing correctly
than it is for an upstream to do it.

If it was my library, I'd be inclined to provide a .pc file for the old
name, that directs API users to link to the library under the new name
(source/API compatibility, but not binary/ABI compatibility); then it's
just like any other SONAME transition, in which you have to keep the old
binary package around until everything depending on it has been rebuilt.

Distributions have to be pretty good at "recompile everything that
depends on libfoo" anyway ("binary non-maintainer uploads" or "binNMUs"
in Debian jargon). If it's a simple recompile, it's easy to automate,
but if source-code changes are needed (even just configure.ac), then
someone needs to edit the source packages and it becomes considerably
more work.

S
Colin Guthrie
2014-01-21 10:45:08 UTC
Permalink
Post by Simon McVittie
Choosing a default linker seems like a system-integration issue rather
than something individual upstreams should be doing.
Yup, I'd rather keep things this way too if possible.

It can often catch integrators off-guard.

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/
Colin Guthrie
2014-01-16 21:36:47 UTC
Permalink
Post by Michael Biebl
Post by Kay Sievers
Post by Michael Biebl
Post by Lennart Poettering
Well, it can certainly continue to use and build against the old version
for a while, no?
We'd have to make pre-systemd-209 and systemd-209 packages
co-installable (different source package names etc.) to be able to
continue to provide the old version. That is not really fun.
Why? The lib is packaged separately, isn't it? What does it have to do
with the systemd package?
Packaged separately in the sense that the systemd source package
builds a libsystemd-daemon0 binary package (among others).
In systemd v209 we could no longer build such a libsystemd-daemon0
binary package from the systemd source package.
We'd have to introduce a separate source package (based on systemd pre
209) named differently then systemd if we want to be able to continue
to build libsystemd-daemon0.
Could we not provide a libsystemd-daemon.so.0 that is just a stub and
links to libsystemd.so.X and just calls the functions therein? That way
the API could still be provided with the old lib (and old .pc files too)
until such times as everything is updated. I would presume the name
mangling would allow for this to work OK with some clever tricks here
and there... (correctly me if I'm wrong)

This would surely be the nicest way to handle things during any
transition phase and could be turned off with a configure switch?

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/
Lennart Poettering
2014-01-16 16:53:02 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
There are some exceptions to this though. For example, I am unsure about
libsystemd-daemon: it's relatively easy to maintain this in its own lib,
sicne so far it actually doesn't use any of the shared code, because
its' embeddable. But then agaiun, given that this library evolves too,
and given that distros generally don't like embedding anyway, we should
probably just merge it into libsystemd.so too, in particular since the
functions it provides are really low-level stuff. libsystemd-dhcp
however really sounds like something that will always be consumer of services, never
provider of services from this new libsystemd.so, and the set of
programs making use of it will always be very small, so we can and
should certainly keep it a seperate lib.
I hope this makes some sense...
Yes, it does. Thank you for the nice summary.
I am also a bit worried about so-bumps: currently we have very nice backwards
compatibility, without any API removals. -daemon, -id128, -journal, -login
are all still .so.0. But libsystemd-bus (libsystemd now) is much harder to
keep this way, among other reasons, because it's much bigger, and much more
experimental.
Well, it's true that we have been pretty good ad keeping compatibility
in the old libraries, but I am quite confident that we can do the same
for the new library. At least that's my personal goal. I'll give the new
APIs a thorough review before we make it official API and I'd welcome if
others did too, so that we have a good chance, we can keep
compatibility.

Lennart
--
Lennart Poettering, Red Hat
Michael Biebl
2014-01-16 16:31:04 UTC
Permalink
Post by Lennart Poettering
So I am pretty sure libsystemd-id128, libsystemd-login,
libsystemd-journal should just end up in a single libsystemd.so together
with the event loop, the bus, the asyncns stuff and more. All this
functinality requires each other, and should nto pull in its own copy of
src/shared/*.c each time.
There are some exceptions to this though. For example, I am unsure about
libsystemd-daemon: it's relatively easy to maintain this in its own lib,
sicne so far it actually doesn't use any of the shared code, because
its' embeddable. But then agaiun, given that this library evolves too,
and given that distros generally don't like embedding anyway, we should
probably just merge it into libsystemd.so too, in particular since the
functions it provides are really low-level stuff. libsystemd-dhcp
however really sounds like something that will always be consumer of services, never
provider of services from this new libsystemd.so, and the set of
programs making use of it will always be very small, so we can and
should certainly keep it a seperate lib.
I hope this makes some sense...
Would that mean you intend to break existing software which uses those
libraries, especially libsystemd-daemon.
Do you intend to at least keep the .pc files so a recompilation would
be sufficient?
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Kay Sievers
2014-01-16 16:37:46 UTC
Permalink
Post by Michael Biebl
Post by Lennart Poettering
So I am pretty sure libsystemd-id128, libsystemd-login,
libsystemd-journal should just end up in a single libsystemd.so together
with the event loop, the bus, the asyncns stuff and more. All this
functinality requires each other, and should nto pull in its own copy of
src/shared/*.c each time.
There are some exceptions to this though. For example, I am unsure about
libsystemd-daemon: it's relatively easy to maintain this in its own lib,
sicne so far it actually doesn't use any of the shared code, because
its' embeddable. But then agaiun, given that this library evolves too,
and given that distros generally don't like embedding anyway, we should
probably just merge it into libsystemd.so too, in particular since the
functions it provides are really low-level stuff. libsystemd-dhcp
however really sounds like something that will always be consumer of services, never
provider of services from this new libsystemd.so, and the set of
programs making use of it will always be very small, so we can and
should certainly keep it a seperate lib.
I hope this makes some sense...
Would that mean you intend to break existing software which uses those
libraries, especially libsystemd-daemon.
Do you intend to at least keep the .pc files so a recompilation would
be sufficient?
The old lib should be able to stay around for older compiled tools as
long as needed.
Linking against the new lib should not create conflicts when the new
lib provides the same symbols.

Kay
Lennart Poettering
2014-01-16 16:45:09 UTC
Permalink
Post by Michael Biebl
Post by Lennart Poettering
So I am pretty sure libsystemd-id128, libsystemd-login,
libsystemd-journal should just end up in a single libsystemd.so together
with the event loop, the bus, the asyncns stuff and more. All this
functinality requires each other, and should nto pull in its own copy of
src/shared/*.c each time.
There are some exceptions to this though. For example, I am unsure about
libsystemd-daemon: it's relatively easy to maintain this in its own lib,
sicne so far it actually doesn't use any of the shared code, because
its' embeddable. But then agaiun, given that this library evolves too,
and given that distros generally don't like embedding anyway, we should
probably just merge it into libsystemd.so too, in particular since the
functions it provides are really low-level stuff. libsystemd-dhcp
however really sounds like something that will always be consumer of services, never
provider of services from this new libsystemd.so, and the set of
programs making use of it will always be very small, so we can and
should certainly keep it a seperate lib.
I hope this makes some sense...
Would that mean you intend to break existing software which uses those
libraries, especially libsystemd-daemon.
Nope, certainly not, we don't want to break this.

Note that all our libraries carry carefully written symbol
versioning. This means you can actually load the old e.g
libsystemd-login.so and the new libsystem.so into to the same process
and the symbols will not clash and thus not create problems. Thus a
smooth upgrade path should be possible for Debian and similar distros
which cannot just recompile everything for the new library (which is
what we'd do for Fedora).
Post by Michael Biebl
Do you intend to at least keep the .pc files so a recompilation would
be sufficient?
No. We'd drop this.

Lennart
--
Lennart Poettering, Red Hat
Simon McVittie
2014-01-16 17:19:18 UTC
Permalink
Post by Lennart Poettering
There are some exceptions to this though. For example, I am unsure about
libsystemd-daemon: it's relatively easy to maintain this in its own lib,
sicne so far it actually doesn't use any of the shared code, because
its' embeddable. But then agaiun, given that this library evolves too,
and given that distros generally don't like embedding anyway, we should
probably just merge it into libsystemd.so too, in particular since the
functions it provides are really low-level stuff.
(Please consider reviewing
<https://bugs.freedesktop.org/show_bug.cgi?id=71818#c5> so dbus will
stop embedding sd-daemon.[ch] :-)

With distro hat on: we don't really care how many clones of a library
are compiled by its "home" source package (for instance, dbus-daemon
statically links a variant of libdbus, but that's fine, because they
both live in the dbus source package). What we care about is that when
there's a serious bug like a security flaw, we want to fix it as few
times as possible, and have the rest of the distro pick it up - so we
don't want to embed copies of libraries in our *other* source packages.

S
Lennart Poettering
2014-01-16 17:41:48 UTC
Permalink
Post by Simon McVittie
Post by Lennart Poettering
There are some exceptions to this though. For example, I am unsure about
libsystemd-daemon: it's relatively easy to maintain this in its own lib,
sicne so far it actually doesn't use any of the shared code, because
its' embeddable. But then agaiun, given that this library evolves too,
and given that distros generally don't like embedding anyway, we should
probably just merge it into libsystemd.so too, in particular since the
functions it provides are really low-level stuff.
(Please consider reviewing
<https://bugs.freedesktop.org/show_bug.cgi?id=71818#c5> so dbus will
stop embedding sd-daemon.[ch] :-)
Done!
Post by Simon McVittie
With distro hat on: we don't really care how many clones of a library
are compiled by its "home" source package (for instance, dbus-daemon
statically links a variant of libdbus, but that's fine, because they
both live in the dbus source package). What we care about is that when
there's a serious bug like a security flaw, we want to fix it as few
times as possible, and have the rest of the distro pick it up - so we
don't want to embed copies of libraries in our *other* source packages.
Yeah, I can understand that. But then again I think sd-daemon.c so far
was trivial enough to make this a non-issue...

But yeah, as mentioned, I am mostly leaning towards dropping the
emebeddability thing, and just telling everybody to link directly
against our lib...

Lennart
--
Lennart Poettering, Red Hat
Zbigniew Jędrzejewski-Szmek
2014-01-25 23:16:00 UTC
Permalink
Post by Lennart Poettering
So I am pretty sure libsystemd-id128, libsystemd-login,
libsystemd-journal should just end up in a single libsystemd.so together
with the event loop, the bus, the asyncns stuff and more. All this
functinality requires each other, and should nto pull in its own copy of
src/shared/*.c each time.
I now pushed a series of patches which merge libsystemd-id128 and
libsystemd-login into libsystemd. I also changed the linker to gold by
default, becuase bfd had a bug [1]. It has since been fixed, but not
released yet, and anyway gold is minimally faster. When running distcheck,
which uses -flto, a bug [2] in gold was uncovered. I worked
around it by disabling lto for the compat libsystemd-login. I doesn't
matter much anyway for this lib. All in all, this doesn't give a good feeling...
I wouldn't be surprised if other issues pop up. I guess it's better to
do this now and potentially revert than right before release.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=16467
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=16504

libsystemd-journal is more complicated. It uses libsystemd-label, which
in turn uses libselinux. Doing a straighforward merge would mean that
everything is linked with libselinux. I think that the idea of splitting
the reporting side of sd-journal and moving it to libsystemd, while
keeping the rest separate, might be a good idea. Comments?

Zbyszek
Post by Lennart Poettering
There are some exceptions to this though. For example, I am unsure about
libsystemd-daemon: it's relatively easy to maintain this in its own lib,
sicne so far it actually doesn't use any of the shared code, because
its' embeddable. But then agaiun, given that this library evolves too,
and given that distros generally don't like embedding anyway, we should
probably just merge it into libsystemd.so too, in particular since the
functions it provides are really low-level stuff. libsystemd-dhcp
however really sounds like something that will always be consumer of services, never
provider of services from this new libsystemd.so, and the set of
programs making use of it will always be very small, so we can and
should certainly keep it a seperate lib.
Lennart Poettering
2014-01-27 14:09:04 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Lennart Poettering
So I am pretty sure libsystemd-id128, libsystemd-login,
libsystemd-journal should just end up in a single libsystemd.so together
with the event loop, the bus, the asyncns stuff and more. All this
functinality requires each other, and should nto pull in its own copy of
src/shared/*.c each time.
I now pushed a series of patches which merge libsystemd-id128 and
libsystemd-login into libsystemd. I also changed the linker to gold by
default, becuase bfd had a bug [1]. It has since been fixed, but not
released yet, and anyway gold is minimally faster. When running distcheck,
which uses -flto, a bug [2] in gold was uncovered. I worked
around it by disabling lto for the compat libsystemd-login. I doesn't
matter much anyway for this lib. All in all, this doesn't give a good feeling...
I wouldn't be surprised if other issues pop up. I guess it's better to
do this now and potentially revert than right before release.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=16467
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=16504
libsystemd-journal is more complicated. It uses libsystemd-label, which
in turn uses libselinux. Doing a straighforward merge would mean that
everything is linked with libselinux. I think that the idea of splitting
the reporting side of sd-journal and moving it to libsystemd, while
keeping the rest separate, might be a good idea. Comments?
Hmm, any idea what precisely the label calls are we make in
libsystemd-journal? Given that this is a client-side library it appears
surprising that it needs to check the selinux database for
something. Maybe we can change this to just not use the label-version of
the respective calls?

Lennart
--
Lennart Poettering, Red Hat
Continue reading on narkive:
Search results for '[systemd-commits] 4 commits - .gitignore Makefile.am man/sd_bus_creds_get_pid.xml man/sd_bus_creds_new_from_pid.xml man/sd_bus_error.xml man/sd_bus_label_escape.xml man/sd_bus_message_get_cookie.xml man/sd_bus_new.xml man/sd_bus_open_user.xml man/sd_bus_request_name.xml src/libsystemd src/libsystemd-bus src/libsystemd-dhcp src/libsystemd-rtnl src/systemd TODO' (newsgroups and mailing lists)
49
replies
[dm-devel] [PATCH] Introducing multipath C API <libdmmp/libdmmp.h>
started 2016-01-28 03:52:00 UTC
dm-devel@redhat.com
28
replies
[systemd-devel] [PATCH v3 0/4] watchdog handling with systemd
started 2012-02-01 16:17:11 UTC
systemd-devel@lists.freedesktop.org
Loading...