|
|
Subscribe / Log in / New account

The Debian init system general resolution returns

The Debian init system general resolution returns

Posted Oct 22, 2014 8:29 UTC (Wed) by johannbg (guest, #65743)
In reply to: The Debian init system general resolution returns by jspaleta
Parent article: The Debian init system general resolution returns

"Now with -shim supporting logind API that original concern has been taken care of. So credit where credit is due. The work to bring logind API support to -shim should be applauded as it definitely is going to benefit Debian users who desire to update systems to jessie and transition to systemd more slowly."

I would take that "support" with a very and I mean very much grain of salt.

systemd-shim package is a futile attempt since the goal that it has to aim for, keeps moving around. There are no stability promises on a core functionality logind uses and as a result of that has left systemd-shim broken for months before and will do so again each and everytime it's (afaik sole ) maintainer Steve Langasek has to play catchup with upstream changes.

Now as it's name indicated requires you to still have systemd installed so the Debian community has the choice of using a) An component which is busy chasing rainbows and developed/maintained by single individual or b) Use systemd with logind and all the other bells and whistle systemd provides which is backup by Tollef Fog Heen, Michael Biebl, Marco d'Itri, Michael Stapelberg, Sjoerd Simon and the entire upstream systemd community.

Now let's return to the core of the matter, the work required by the Debian, ( as well as Gentoo,Slackware and whomever intents to support multiple and or use alternative init system than systemd whatever they may be called uselessd,openrc,sysvinit etc in the long run ) community has to come up with ( and the systembsd maintainer bumped into as well and significantly slowed down the development or grounded his development to halt entirely ).

In *addition* having to carry downstream compatibility patches for all upstream components that have decided to integrate/use what systemd provides them with *beside* logind and the added load on the service support community ( help,qa,releng etc ) and it's maintainers that will bring, they will need to write and thus provide a daemon that provides the external, supported, and guaranteed stable "login" API, an daemon that maps the "login" API to the non-portable operating-system-specific underpinnings which is an hefty chunk of development work.

You cant workaround this problem in apt through some dependency/resolving magic and you wont achieve this with something like systemd-shim or have it magically appear by whining about it on mailing lists, in forum, and various comment sections or by continually coming up with GR's and the likes, you actually need to get your hands dirty and start doing that hefty coding period.

Ian and his followers are doing pretty good job disrupting the Debian community from doing what needs to be done to make Jessie the most awesome release ever ( integrate it to the best of it's ability to systemd. I've been midst in this integration work myself and I know how much it pains users have things half integrated, half migrated and thus half working ) and ensuring Jessie will become the worst release ever by having no init working reliably since him and his followers are not coming up with components and the code necessary to do so.

I just sincerely hope for the sake of Debian that the DD will vote for Luca Falavigna proposal ( Choice 3 ) which will put this power into the hands of the maintainers themselves since I know quite few of them know the reality for what it is but have chosen to keep themselves outside any ( systemd ) discussion and mud sliding.


to post comments

The Debian init system general resolution returns

Posted Oct 22, 2014 15:40 UTC (Wed) by jspaleta (subscriber, #50639) [Link] (2 responses)

oh indeed -shim is useful only insofar as it aids people to transition upgraded systems to systemd across the wheezy/jessie boundary as they port local custom configuration to systemd semantics. I don't think its a long term solution.

point of information. I think ryan lortie is primary committer upstream.

both U and D bzr packaging systems suck in the upstream releases from ryan and seem to be point to http://people.gnome.org/~desrt/ as the source

Ryan seems to be using github primarily, but not github's release tagging mechanism, so the tarballs in http://people.gnome.org/~desrt/ are probably the canonical upstream release source.

Steve is acting primarily in the role of distribution packaging maintainer I think. And Martin Pitt is committing at both the distro and upstream levels.

Anyways... Ryan had a lovely blog post back in Feb, which I believe concurs with your assessment of the difficulty of using -shim to mimic the full systemd API. I think he draws different conclusions than you do from that. Considering what Ryan posted in Feb, I'm actually surprised that they got -shim updated to support logind. His post implied to me that it wasn't going to be attempted.
ref: http://blogs.gnome.org/desrt/2014/02/19/on-portability/

Seems -shim grew all the necessary cgroups stuff since september looking at ryan's github for -shim.

-jef

The Debian init system general resolution returns

Posted Oct 22, 2014 17:45 UTC (Wed) by johannbg (guest, #65743) [Link] (1 responses)

"Seems -shim grew all the necessary cgroups stuff since september looking at ryan's github for -shim."

Which happens to be one area him and or him and Martin will be constantly playing catchup with systemd.

I would not be surprised if they will only continue to maintain it until unity/ubuntu catches up with systemd and at that point they loose interest.

In anycase bottom line still remains the same if people want to ( continue to ) use alternate init system(s), be it single or plural instead of systemd in the name of choice or disgust towards systemd, individual members of the systemd community or the systemd community in whole, those individuals *will* have to code up/beef up those existing init system ( or write one from scratch ) to be somewhat on par with systemd. Once they have achieved that then they will have to convince wide variety of upstreams that currently use systemd to support that and or integrate it with their alternative.

The Debian init system general resolution returns

Posted Oct 22, 2014 18:27 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

I concur as to where the burden to find the manhours to keep -shim compatible will have to be found. I also agree with as to the speculation that interest in staffing much of the existing manpower will wane once Ubuntu makes the transition from upstart to systemd. I think the Uphone RTM images still use upstart, which does complicate the timescale on which Canonical can fully accomplish that transition.

What I don't really have my head around is what the plan is for updating systemd in either U or D and how conservative the systemd packaging updating is going to be. Both could basically peg systemd to a specific upstream version and skip some upstream releases in an effort to lower the risk of creating an API delta that -shim will have to keep up with.

I expect work on -shim compatibility to be bursty...and only happen for upstream versions of systemd that land in Ubuntu pre-release packaging, even if systemd versions roll into Debian unstable/experimental on a more regular fashion thanks to the effort of the systemd debian maintenance team. So I expect to see a delta to build up in the Debian unstable/experimental repo just to the differences in available attention and interest in tracking upstream systemd.

I'm willing to see this admitted low expectation on -shim work to be surpassed and I'll take any well deserved lumps for discounting the commitment of the people working on -shim if they are able to keep the delta between -shim and systemd API coverage low without another 4+ month lapse in -shim activity.

-jef


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds