FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 08-28-2012, 09:13 AM
Lukas Jirkovsky
 
Default merging systemd back to a singular package

On 28 August 2012 11:05, Tom Gundersen <teg@jklm.no> wrote:
> On Tue, Aug 28, 2012 at 10:54 AM, Lukas Jirkovsky <l.jirkovsky@gmail.com> wrote:
>> I'm pretty sure at least Ubuntu will keep patches to make some of such
>> apps work without systemd.
>
> So far we see that whenever systemd is made optional, it is optional
> at compile-time rather than at run-time (which would have been ideal,
> and not much more difficult to code). That means our packages cannot
> support both scenarios at the same time.

That's why I'm think about maintaining such packages in community.

> As to Ubuntu, remember that they lag quite far behind our packages, so
> while they probably will produce patches, don't expect it to happen in
> time for it to help us. Notice for instance that Ubuntu supposedly
> took over consolekit, but no release has happened and without
> backporting patches from git our consolekit package would be
> completely broken.
>
> In short: avoiding systemd will be a lot of work, and you will be more
> or less alone in doing it.
>
> -t

Unless there's going to be some major rewrite of the affected packages
in the meantime I think I'll be able to handle that. During the years
I'm using OSS, I learned one thing: If no one else wants to do
something, you must do it yourself.

Lukas
 
Old 08-28-2012, 10:06 AM
Nicolas Sebrecht
 
Default merging systemd back to a singular package

The 28/08/12, Tom Gundersen wrote:

> I guess what I wrote was a bit misleading. Ignore socket/dbus
> activation (that is a side effect only). The point is that I don't see
> how to make daemons of Type=simple (the default), Type=dbus or
> Type=notify work without reimplementing much of systemd (regardless of
> when/how they are started).
>
> The point is that those kinds of daemons have moved functionality out
> of the daemon itself and into systemd, so the analogous must be done
> in the rc scripts.

Well, sd_notify looks pretty simplistic and I guess than writting a
helper program to handle this function would not be hard, if ever
needed.

Now, the simple type of systemd pretends to do optimization:

"if the process offers functionality to other processes on the system
its communication channels should be installed before the daemon is
started up [...] as systemd will immediately proceed starting
follow-up units."

While it's a good feature to get pallelism, it's not expected by
historical sysVinit. So, it should be fine to start the required deamon
and let it configure environment or whatever it has to. Once it is fully
started or responding, continue the boot process. Yes, this "fully
started or responding" is the tricky part but with a fully serialized
starting process, it might be doable.

Though, I wouldn't expect such converter to create shell scripts roughly
equivalent to what systemd does. I think the main pitfall to such a tool
would be to try to get equivalent features with shell scripts.

Think another way: sysVinit serialize daemons startup. As a consequence,
for a minimal working convertion you only need to get the correct order
of the series. Advanced features of systemd should highly be ignored
from the process.

On top of that and for tricky parts of the conversion, it should not be
very hard to have conversion tunning from a complementary static source.
I mean, trying to convert everything /from unit files only/ in a smart
enough way could be very hard. Instead, it would be easier to do the
consersion from both unit files AND whatever other source or
configuration files (of the convertion tool).

IMHO, the best approach of this converter would be to turn it into a
micro-framework with _very simple features_ like templating support for
init scripts.
That way:
- simple unit files would not require a template; let the process go
automagically;
- more complex unit files would only require to write a little template
with whatever static-and-dedicated code needed for a given
section/function of the built target (the sysVinit script).


The systemd-to-sysvinit-converter seems very hackable as a all-in-one
python script with only 658 lines. ,-)


> Hopefully the Debian guys have found a clever solution for this, I'd
> be interested to see it

I guess you meant "if the Debian guys have found".


--
Nicolas Sebrecht
 
Old 08-28-2012, 10:18 AM
Tom Gundersen
 
Default merging systemd back to a singular package

On Tue, Aug 28, 2012 at 12:06 PM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> "[...]its communication channels should be installed before the daemon is
> started up [...]"

This is the point. If a daemon has been customized for systemd (which
some have, and hopefully more will), then it will expect systemd to
set up its communication channels for it and pass them to the daemon
on startup, it might also expect systemd to do many other tasks which
daemons traditionally would do themselves.

This is by no means impossible to reimplement, but it would be quite
some work, so it is something to keep in mind.

-t
 
Old 08-28-2012, 10:32 AM
Nicolas Sebrecht
 
Default merging systemd back to a singular package

The 28/08/12, Tom Gundersen wrote:

> This is the point. If a daemon has been customized for systemd (which
> some have, and hopefully more will), then it will expect systemd to
> set up its communication channels for it and pass them to the daemon
> on startup, it might also expect systemd to do many other tasks which
> daemons traditionally would do themselves.

Daemons customized to require systemd will actually require systemd.

Now, systemd is a Linux only platform tool and most upstream don't
target their software to Linux only. I don't expect much daemons
requiring systemd to be started. If they do, users who want such tool
will use systemd and such daemons would naturally be out of the scope.

--
Nicolas Sebrecht
 
Old 08-28-2012, 11:46 AM
Kevin Chadwick
 
Default merging systemd back to a singular package

> at some point other packages are
> likely to depend on you booting with systemd (NetworkManager, polkit,
> Gnome, etc.).

Do you mean the packages compiled for Arch with systemd enabled
options like firefoxes with dbus? I don't see these packages removing
more than half their userbase and I don't see systemd ever getting
more than half the userbase.

--
__________________________________________________ _____________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
__________________________________________________ _____________________
 
Old 08-28-2012, 11:52 AM
Kevin Chadwick
 
Default merging systemd back to a singular package

> I'm pretty sure at least Ubuntu will keep patches to make some of such
> apps work without systemd. I can maintain these in community if that
> time comes. But I can care about KDE only, making GNOME work without
> systemd would be a too difficult (I don't use it and they are much
> more likely to require systemd than KDE). Fortunately KDE currently
> uses only one library (polkit) that is likely to switch to systemd in
> near future.

Personally I live happier without polkit but for others it may be if
the build machines don't mind that arch could have kde-nosystemd
packages?

--
__________________________________________________ _____________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
__________________________________________________ _____________________
 
Old 08-28-2012, 06:02 PM
Zeke Sulastin
 
Default merging systemd back to a singular package

On Tue, Aug 28, 2012 at 6:55 AM, Jayesh Badwaik
<jayesh.badwaik90@gmail.com> wrote:
> Hi,
>
> Apparently, Gentoo has recently forked udev. [1] I am not completely
> sure since the main poster is a n00b according to the gentoo forum
> ratings, but rest of the discussions seems legit.

Actually, a guy forked it and announced it on Gentoo's forums; the
distro itself currently has nothing to do with it, although as Gentoo
is planning on using OpenRC over systemd any news about a udev fork is
interesting to them [2]. I'm not sure I'd call the less than one page
of discussion "legit" though - it looks to me like a little bit of
building discussion and a lot of the same crap that's been infecting
our own mailing list (plus consus' "advantages" are suspect - just
going on the first one, a separate /usr not mounted in initramfs has
been broken since long before systemd-udev, and in my quick look at
commits I don't really see anything they've added that would change
that esp. since it's not just udev that's the issue. If Gentoo devs
get on board it might go somewhere, but until then I'm not that
confident.)

[1]https://forums.gentoo.org/viewtopic-t-934678.html
[2]http://www.reddit.com/r/linux/comments/ywdpw/systemdudev_has_been_forked/c5zwz0n
 

Thread Tools




All times are GMT. The time now is 09:38 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org