Re: systemd as external dependency

On Wed, 18.05.11 18:03, Josselin Mouette (joss debian org) wrote:

> Le mercredi 18 mai 2011 à 17:30 +0200, Lennart Poettering a écrit : 
> > It's not just some #ifdefs. It's a ton. Lemme list a couple of Linux
> > specific interfaces that are used in systemd, you'd have to find
> > replacements for:
> > 
> > - get_current_dir_name()
> > - canonicalize_file_name()
> (Just to be pedantic: these are from glibc, so are available with
> kFreeBSD as well.)
> > And this is just what I found while going through two files in
> > systemd. Of course, a couple of these are easy to emulate, or have
> > obvious counterparts on the other OSes, or could be made optinal (or
> > even are already optional), but the point I want to make here is that it
> > wouldn't be a couple of #ifdefs. 
> Sure, but what if people want to do the job?

They are welcome to do so. But I won't litter my simple sources with
it. I do not want to think about ifdefs about abstractions. I don't want
to think which OS I am breaking now when I add something new to systemd.

You know, I maintain a lot of software, like Avahi and PulseAudio for
example. These two are big projects, and both of them are portable, to
the weirdest Unixes. And have been ported to them. I *know* the burden
portability brings with it. I know it better than most people. I think I
know it better than you.

The lower you get in your stack the heavier the burden of portability
becomes. While top level apps might have little problems maintaining
compat with other OSes by using glib and friends the closer the come to
the kernel the more you need to deal with kernel APIs, and the more
work, the more ifdefs, the more madness it becomes to support multiple

systemd is the lowest-level component in our entire stack, isn't it
kinda obvious then that making it portable is simply crazy?

> > It would turn every second line of systemd into #ifdefs. And I
> > wouldn't want to maintain such a beast.
> > 
> > That all said, git is your friend. If people want to port this over to
> > other systems, they are welcome to do so and with "git rebase" they
> > could keep it somewhat up-to-date. I will not share your suffering if
> > you do.
> Ah right, people won’t do the job, because you give them the finger from
> the very beginning. Sure. What could we need more right now than another
> glibc/eglibc disaster with a maintainer who doesn’t want to care about
> more than his chapel?

Thanks, I'll call it Josselin's law: "As an online discussion grows
longer, the probability of a comparison involving Ulrich Drepper
approaches 1.".

> Note that this is the primary reason preventing us from making good use
> of systemd features in Debian. This would imply, for each package
> providing a daemon, to maintain a sysv init script for insserv a service
> for systemd. So we’re stuck, at best, with using only the lowest common
> denominator between init systems.
> In the end, this behavior is not just making the life of porters
> impossible; it is making harder to actually embrace your software.

Dude, you are turning everything from its feet onto the head:

I am not making things difficult: you are yourself making things
difficult. Debian kFreeBSD is a toy OS. About 10 people on this earth
use it. About 0.4 of those probably run GNOME on it. Of that half a
person only about 0.2 probably expect it to work properly.

I am not sure why you ask me to care about your interest into toy
OSes. I am not sure why you think that your interest in toy OSes should
set the agenda for GNOME.

Also, I can only repeat: the cooperation mode with your OSes and systemd
should be sharing interfaces, not sharing code.


Lennart Poettering - Red Hat, Inc.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]