Re: question re. packaging, build, init and shepherd

[Christopher Baines]

Miles Fidelman <address@hidden> writes:

>>> And then there's the question of init systems:  Until systemd came
>>> along, ./configure;make;make install generally just works - leaving
>>> init files in the right places, starting up daemons, etc.
>>>
>>> Which leads to the question of, if I want to install something
>>> complicated in GUIX - say the Sympa list manager (to pick a non-random
>>> example), which comes with standard sysvinit scripts - can I just
>>> ./configure;make;make install?  Does Shepherd do the right thing with
>>> sysvinit scripts?  Can I invoke them through Shepherd (e.g, after a
>>> config change)?  Can I still edit & invoke the init scripts in the
>>> classic ways (vi, /etc/init.d/<foo> restart).
>> The configuration of the shepherd is normally entirely managed through
>> your Guix operating-system definition. The configuration is generated in
>> te store, and shepherd looks at that.
>>
>> This is important as it allows you to boot in to previous generations of
>> your system, which is useful for recovering the system if things go
>> wrong.
>>
>> So, whereas I think things like systemd are aware of sysvinit scripts in
>> the usual place, the shepherd is completely unaware.
>
> So... that kind of leaves out automatically setting up servers. I
> mean, most server software still comes with init files, maybe with
> systemd or other init files, but generally make install sets things up
> so that servers start & run.
>
> So how does GUIX support this?
>
> And, for that matter, how does GUIX handle any kind of post-install
> configuration?  E.g., the kind of things that debconf might be used
> for.

So, I used to write Debian packages, including the debconf stuff, so I
have some experience of this

While a Debian package installs effectively with root privileges and can
modify the state of the system as much as it wants to, when you install
a Guix package, all you're saying is I want these specific things to
exist in /gnu/store, make it so. When you install a Guix package,
nothing can be changed, you're only adding entries to the store, if they
weren't already there.

With Debian packages, the service management can be included in the
package, so you can dpkg-reconfigure the package, and have the debconf
scripts modify the configuration for you.

With Guix, packages are entirely separate from services, services just
use packages. Guix has a framework for defining services and managing
the configuration.

So, like packages, the best way of getting a service running on a Guix
System, is to write a service-type definition. This can be quite short,
if the configuration is simple, or you don't manage it. Or they can be
quite complex if lots of the configuration can be managed from Guile.

So, Guix supports system services through it's own abstraction.

Hope that helps,

Chris

signature.asc
Description: PGP signature