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-27-2012, 02:12 PM
"Stephen E. Baker"
 
Default merging systemd back to a singular package

On 27/08/2012 9:39 AM, Heiko Baums wrote:

Am Mon, 27 Aug 2012 11:30:46 +0200
schrieb Joakim Hernberg <jbh@alchemy.lu>:


I don't run gnome, but kde is just as bad in this case

Try Xfce. ;-)

http://www.archlinux.org/packages/extra/i686/consolekit/ would suggest
that xfce is not safe in this regard. lxde is as long as you don't use
a display

manager iirc.

Heiko
 
Old 08-27-2012, 03:21 PM
Lukas Jirkovsky
 
Default merging systemd back to a singular package

On 27 August 2012 10:40, Tom Gundersen <teg@jklm.no> wrote:
> On Aug 27, 2012 10:32 AM, "Joakim Hernberg" <jbh@alchemy.lu> wrote:
>> Please support our traditional initscripts as long as possible,
>
> I will. I just don't know how long that will be, so people should prepare
> to move.
>
> Tom

I can help (or at least try to) with support for initscripts if it's
going to be a burden for you some day in the future. I won't give up
using initscripts on my desktop so easily ;-).

Lukas
 
Old 08-27-2012, 04:16 PM
Tom Gundersen
 
Default merging systemd back to a singular package

On Mon, Aug 27, 2012 at 5:21 PM, Lukas Jirkovsky <l.jirkovsky@gmail.com> wrote:
> I can help (or at least try to) with support for initscripts

Anyone who wants to help, please join arch-projects@archlinux.org,
review patches, use initscripts from git/testing and report problems.

> if it's
> going to be a burden for you some day in the future.

As has been mentioned, the problems I foresee are (ordered from
"currently a problem" to "a potential problem a long time from now":

1) not enough people testing initscripts. This would be easy to help
out with :-)
2) third-party software (such as gnome/polkit/...) getting hard
dependencies on booting with systemd (essentially everything that now
depends on consolekit, and maybe more). If you don't use the affected
software this does not matter, if you do it is not really easy to work
around.
3) devs at some point no longer wanting to maintain the various rc
scripts. If people are committed enough I guess an "rc scripts"
package could be put in the AUR to deal with this case (if ever it
becomes a problem, which it might not).

> I won't give up
> using initscripts on my desktop so easily ;-).



-t
 
Old 08-28-2012, 03:35 AM
Sujith
 
Default merging systemd back to a singular package

Thomas Bächler wrote:
> > Please support our traditional initscripts as long as possible, as I for
> > one really don't look forwards to systemd, at least not at this point
> > in time. Reasons excluded to avoid yet another flamefest...
>
> If you search the archives, you will notice that longer initscripts
> support is already planned.
>
> But this only concerns the booting itself. As consolekit is
> unmaintained, polkit will soon depend on systemd. The next Gnome version
> will require systemd - more to come.
>
> That said, if you run a machine that does not depend on any of this
> (like a server), you will probably be able to keep using traditional
> initscripts for a while.

This is good news !

I maintain a bunch of test-machines (about 10) in a lab and the prospect of moving
all of them to a new init system is a bit scary - they are all in a remote place.
My environment is openbox/emacs, so initscripts is a perfect fit. Having just moved
all the machines to grub2 and resolved the /lib migration, embracing systemd right now
appears to be a tiresome job. :-)

And I have a server which I stopped upgrading a while ago.

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

The 27/08/12, Tom Gundersen wrote:

> As has been mentioned, the problems I foresee are (ordered from
> "currently a problem" to "a potential problem a long time from now":
>
> 1) not enough people testing initscripts. This would be easy to help
> out with :-)
> 2) third-party software (such as gnome/polkit/...) getting hard
> dependencies on booting with systemd (essentially everything that now
> depends on consolekit, and maybe more). If you don't use the affected
> software this does not matter, if you do it is not really easy to work
> around.
> 3) devs at some point no longer wanting to maintain the various rc
> scripts. If people are committed enough I guess an "rc scripts"
> package could be put in the AUR to deal with this case (if ever it
> becomes a problem, which it might not).

Notice that debian is working on a tool to automagically convert unit
systemd files into initscripts.

https://github.com/akhilvij/systemd-to-sysvinit-converter

Might be worth giving it a try and contribute to get easier support of
sysvinit in the long term.

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

On Tue, Aug 28, 2012 at 8:57 AM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
> Notice that debian is working on a tool to automagically convert unit
> systemd files into initscripts.
>
> https://github.com/akhilvij/systemd-to-sysvinit-converter

If that works, it would be great. However, I'm very skeptical. I don't
see how this could possibly work for services of type other than
"forking" (i.e., how to simulate socket/dbus activation). As we hope
that as few services as possible will be using Type=forking, that is a
problem. Having had a brief look through the code/documents I see no
mention of this issue, but maybe I'm missing something obvious...

-t
 
Old 08-28-2012, 08:24 AM
Guus Snijders
 
Default merging systemd back to a singular package

Op 28 aug. 2012 10:06 schreef "Tom Gundersen" <teg@jklm.no> het volgende:
>
> On Tue, Aug 28, 2012 at 8:57 AM, Nicolas Sebrecht <nsebrecht@piing.fr>
wrote:
> > Notice that debian is working on a tool to automagically convert unit
> > systemd files into initscripts.
> >
> > https://github.com/akhilvij/systemd-to-sysvinit-converter
>
> If that works, it would be great. However, I'm very skeptical. I don't
> see how this could possibly work for services of type other than
> "forking" (i.e., how to simulate socket/dbus activation). As we hope
> that as few services as possible will be using Type=forking, that is a
> problem. Having had a brief look through the code/documents I see no
> mention of this issue, but maybe I'm missing something obvious...

Actually, that sounds like a fairly small issue...

With most daemons i prefer to either start them at boot or not at all.
In case any daemon requires socket activation, you can use xinetd for those.

mvg, Guus
 
Old 08-28-2012, 08:31 AM
Tom Gundersen
 
Default merging systemd back to a singular package

On Tue, Aug 28, 2012 at 10:24 AM, Guus Snijders <gsnijders@gmail.com> wrote:
> Op 28 aug. 2012 10:06 schreef "Tom Gundersen" <teg@jklm.no> het volgende:
>> If that works, it would be great. However, I'm very skeptical. I don't
>> see how this could possibly work for services of type other than
>> "forking" (i.e., how to simulate socket/dbus activation). As we hope
>> that as few services as possible will be using Type=forking, that is a
>> problem. Having had a brief look through the code/documents I see no
>> mention of this issue, but maybe I'm missing something obvious...
>
> Actually, that sounds like a fairly small issue...
>
> With most daemons i prefer to either start them at boot or not at all.
> In case any daemon requires socket activation, you can use xinetd for those.

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.

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

Cheers,

Tom
 
Old 08-28-2012, 08:54 AM
Lukas Jirkovsky
 
Default merging systemd back to a singular package

On 27 August 2012 18:16, Tom Gundersen <teg@jklm.no> wrote:
> On Mon, Aug 27, 2012 at 5:21 PM, Lukas Jirkovsky <l.jirkovsky@gmail.com> wrote:
>> I can help (or at least try to) with support for initscripts
>
> Anyone who wants to help, please join arch-projects@archlinux.org,
> review patches, use initscripts from git/testing and report problems.
>> if it's
>> going to be a burden for you some day in the future.
>
> As has been mentioned, the problems I foresee are (ordered from
> "currently a problem" to "a potential problem a long time from now":
>
> 1) not enough people testing initscripts. This would be easy to help
> out with :-)

For some reason I always find problems after some time when
initscripts are already in core.

> 2) third-party software (such as gnome/polkit/...) getting hard
> dependencies on booting with systemd (essentially everything that now
> depends on consolekit, and maybe more). If you don't use the affected
> software this does not matter, if you do it is not really easy to work
> around.

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.

Lukas
 
Old 08-28-2012, 09:05 AM
Tom Gundersen
 
Default merging systemd back to a singular package

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.

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
 

Thread Tools




All times are GMT. The time now is 06:21 AM.

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