On Thu, Apr 26, 2012 at 11:50:51PM +0800, Thomas Goirand wrote:
> On 04/26/2012 08:42 PM, Roger Leigh wrote:
> > If anyone fancies
> > doing the packaging, I'll be happy to join in. I'll probably be able
> > to provide a better overview once I know a bit more.
> I don't know much about OpenRC apart from what Patrick told me,
> but I'd be happy to discover it. Maybe I can start packaging with
> Patrick together, and with you as well.
That sounds great. I'm equally in the dark regarding OpenRC, though
I've checked the git repo out and had a chat on IRC with some of the
developers. My initial impressions are that it adds some very nice
features which are lacking in our current default sysvinit setup,
while not going quite as far as systemd/upstart. Certainly a very
nice upgrade to what we currently have, while not being as radical a
change as the other alternatives. Other than replacing the /etc/rc?.d
symlink farms with /etc/runlevels/name (and most of us really don't
care about runlevels directly), it's pretty much identical from the
user's POV.
I've taken the liberty of creating a repo on collab-maint for Debian
packaging. git://git.debian.org/git/collab-maint/openrc.git
It's currently just branched from the current upstream repo with
no changes.
> I've read others writing that they don't like the LSB headers. I'd like
> to know why. What's wrong with it? I find ok-ish. Sure perfectible,
> sure the syntax is a bit stupid and verbose for no reasons, but that's
> not *that* bad. So, could you tell why you think it's bad? (this of
> course isn't aimed at Roger specifically, but to everyone)
Two issues that come to mind
- it's not permitted for a package to declare that it provides a
virtual service, e.g. $cron. This is actually in the LSB spec.
OpenRC does allow this. There are several bugs about this.
- it's just a block of text inside a shell script comment. Not the
nicest thing to parse. In comparison systemd is entirely
declarative. OpenRC is sort-of declarative inside a shell function,
but is actually part of a script so you can define them
programatically as well from what I can tell, which would mean it
might be possible to conditionally depend on things.
depend()
{
need localmount
keyword -jail -openvz -prefix -vserver -lxc
}
depend()
{
need localmount
after bootmisc
provide net
keyword -jail -vserver
}
> Next: if the LSB headers are bad, what are our options to move
> away from them? Should we do some kind of tools to convert them
> to a better, simpler format? How does it work with systemd for
> example? I've just read about .depend files, how are they handled?
The .depend files are an internal implementation detail of startpar
and insserv. insserv generates them from the LSB headers, while
startpar uses them to parallelise startup. If you take a look, you'll
see that it's basically Makefile-style dependencies.
systemd unit files are purely declarative descriptions of services.
It uses socket-based activation to defer starting services, similar
in concept to inetd I guess, but encompassing much much more. So
a service will get started when something tries to connect to it,
which will block until it's available. It's a really nice concept.
I've not figured out exactly how the OpenRC dependencies work, or if
it's possible to dump them by running the script. I've had a small
look, but not had enough time to familiarise myself with it all yet.
> I agree that best would be if OpenRC was a simple drop-in replacement
> for insserv, and if it supported what we currently have *PLUS* some
> new features (which have already been discussed during huge threads,
> I don't feel like enumerating them again...). If it doesn't, then maybe
> I can beat-up^Wmotivate Patric to work toward that goal of
> supporting our already existing infrastructure.
>
> I'm not sure where all this will lead me/Debian, but I think this is
> worth a try. I'll try to catch-up with Patrick and talk with him about
> how we can start doing this. Maybe we can also have a round table
> about this during Debconf12...
I think it's definitely worth exploring. From our chatting on IRC, I
think the following came out of it:
- We need LSB dependency support in OpenRC in order to support all the
init scripts in Debian which utilise them. Definitely required in
order to make it possible to evaluate OpenRC without converting the
entire distribution immediately.
- Converting all our core initscripts probably isn't a massive task.
It can probably be done inside a weekend. There's undoubtedly a
large amount of overlap with the OpenRC scripts, which would need
removing/replacing where appropriate.
- Given that runlevels have names rather than numbers, we would need
to look into how update-rc.d interacts with OpenRC. Conversion of
/etc/rc?.d to /etc/runlevels (and in reverse) also needs
investigation. For update-rc.d we could probably map the standard
0/1/2/6 numbers to the OpenRC boot/single/default/shutdown names.
- Debian's support of multiple init systems makes migration to and
from OpenRC difficult. At the present, sysvinit/initscripts is the
default, and alternatives may be installed to replace them in whole
or in part:
- file-rc
- systemd
- upstart
upstart is the most difficult to deal with. Unlike systemd, which
allows both units and init scripts to be provided together, upstart
requires (if I understand correctly) either an init script or an
upstart job, but not both. But all support LSB init scripts as a
basic part of their functionality. They key point is that LSB
initscripts are the lowest common denominator, and changing init
systems generally involves going via sysvinit as the intermediate
step.
Were we to replace sysvinit/startpar/insserv with OpenRC, it would
replace LSB initscripts as the lowest common denominator with
OpenRC initscripts (while also supporting LSB initscripts). While
this change in itself would be fairly simple, in order to continue
to permit other init systems to replace it, it would require some
degree of support for OpenRC scripts in systemd, upstart etc. This
probably amounts to teaching systemd how to extract the necessary
dependency information as it presumably already does for the LSB
headers, and the equivalent process for the others. They might
also need to provide a replacement /sbin/runscript.
So to get started with OpenRC, we need LSB header support. Everything
else can come later, should we want to make it the default.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120426230935.gc28...@codelibre.net
