Re: question re. installing software & init system

[Thompson, David]

On Fri, Jan 1, 2016 at 12:52 PM, Miles Fidelman
<address@hidden> wrote:
> Thanks!  Some follow-ups inline, below....
>
>
> On 12/31/15 5:41 PM, Thompson, David wrote:
>>
>>> Several specific questions:
>>>
>>> The recent PPT presentation on GUIX (to Inria) implies that packaging can
>>> be
>>> as simple as writing a config file that tells GUIX to do a "config; make;
>>> make install" on a source file built with the GNU tools
>>> - do I NEED to package something or can I simply do a basic download,
>>> untar,
>>> config, make, make install on a running system?
>>
>> No, you don't have to make a package to use software.  GuixSD is,
>> after all, a GNU/Linux system where you can build and run custom
>> software without ever telling the package manager about it.  Do note
>> that we have no global /usr directory, so you'd want to choose where
>> 'make install' will install things by running './configure
>> --prefix=/whatever' when building software that uses the GNU build
>> system.  Ideally, you'd want everything to be managed by Guix so that
>> you could benefit from all the nice features like transactional
>> upgrades and rollbacks, but for quick one-off hacks you can go rogue
>> just as you could on Debian or Trisquel or any other distro.
>
>
> Does GuixSD respect the LSB, and in particular /usr/local/.... ?

No.  We don't use LSB, nor do we conform to the FHS, because they
conflict with functional, stateless system management.  Of course, you
could 'mkdir -p /usr/local' on a GuixSD system and do whatever you'd
like.  In Guix, all software builds are kept in /gnu/store, and each
user on the system maintains one or more "profiles" that reference
some subset of the software available in the store.  This gives each
user the freedom to use the software of their choosing, without
worrying about global conflicts with the system or other users.  Thus,
/usr is obsoleted.

For more information about profiles and other per-user package
management features, see:
https://gnu.org/software/guix/manual/html_node/Invoking-guix-package.html#Invoking-guix-package

>>> - does dmd handle standard sysvinit files (as are still most commonly
>>> included in source packages)?
>>
>> No, dmd services are Scheme expressions, rather than ad-hoc Bash
>> scripts.  For example, here's a custom dmd service I wrote awhile back
>> to manage my music player daemon:
>>
>>      (make <service>
>>         #:provides '(mpd)
>>         #:requires '()
>>         #:start (lambda args
>>                   (define (scope file)
>>                     (string-append (getenv "HOME") "/.config/mpd/" file))
>>
>>                   (unless (file-exists? (scope "playlists"))
>>                     (mkdir (scope "playlists")))
>>                   (touch-file (scope "database"))
>>                   (fork+exec-command
>>                    (list "mpd" "--no-daemon"(scope "mpd.conf"))))
>>         #:stop (make-kill-destructor))
>>
>> The dmd manual can be found here:
>> http://www.gnu.org/software/dmd/manual/html_node/index.html
>
>
> I was afraid of that.  It's pretty standard for source code to include
> sysvinit files; I doubt anybody includes dmd service files. Kind of breaks
> most standard service installs.

GuixSD has a service API built into the system configuration system.
The reason for using an init system written in Guile Scheme is that we
get a much better programming interface (Scheme vs. Bash) and can
share a great deal of code between Guix and the service layer.
Sysvinit, systemd, etc. are just not a good fit for us.

> It doesn't look like sysvinit is packaged for GuixSD - it sure would be nice
> to support compatibility.  That would go a long way toward making GuixSD a
> usable distribution.  (One man's opinion.)

Well, one should be able to easily package sysvinit for Guix, but
GuixSD will never use it as PID 1 because it doesn't meet our needs.
Sysvinit is, IMO, antiquated and undesirable.

>>> - and the there's the whole set of issues, recently raised, related to
>>> language systems that maintain their own repos and build systems (e.g.,
>>> CPAN) -- somehow, partial import of dependencies into the GUIX
>>> environment
>>> does not seem usable
>>
>> Like other distros, we work on providing a means to package any type
>> of software with Guix.  We have defined build systems to build
>> software in a variety of languages like Python, Ruby, Perl, R, and
>> Emacs Lisp.  Additionally, we have a tool called 'guix import' to help
>> automate some of the package recipe writing process by using the data
>> available on PyPI, RubyGems, CPAN, CRAN, ELPA, etc.
>>
>> Why do you think that using Guix for languages beyond C isn't usable?
>
> Well... speaking just for CPAN - I use several perl-intensive packages on
> our production system.  I almost always find that a cpan-based install
> works.  Trying to install via apt, rarely works. It's a matter of keeping
> stuff up to date.

This is why we have the 'guix import' and 'guix refresh' tools, to
make it easier to create the initial packages for these things, and
make updating them later easier.  There is, of course, much work to be
done, but it's very usable right now.  The pains of dealing with
language-specific package managers all day, every day is what lead me
to Guix in the first place.

Also, it is *much* easier to write Guix package recipes than it is to
deal with dpkg/yum/etc.  Typically a package is a very brief Scheme
expression.  Here's an example:

    (define-public perl-scalar-list-utils
      (package
        (name "perl-scalar-list-utils")
        (version "1.41")
        (source
         (origin
           (method url-fetch)
           (uri (string-append "mirror://cpan/authors/id/P/PE/PEVANS/"
                               "Scalar-List-Utils-" version ".tar.gz"))
           (sha256
            (base32
             "04l1q4hps9n8b1hk9kpgpc1cryim7pl9sfdyb7fz5nq4gmz307j7"))))
        (build-system perl-build-system)
        (home-page "http://search.cpan.org/dist/Scalar-List-Utils";)
        (synopsis "Common Scalar and List utility subroutines")
        (description "This package contains a selection of subroutines
that people
    have expressed would be nice to have in the perl core, but the
usage would not
    really be high enough to warrant the use of a keyword, and the size so small
    such that being individual extensions would be wasteful.")
        (license (package-license perl))))

You can see more Perl package recipes here:
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/perl.scm

> I'll simply repeat what I said above - when doing things radically
> differently, writing the documentation first helps a lot.  When I need to
> dive into the Debian installer, I can generally find enough detail (not
> necessarily in one place).  (IMHO) Way too much of Guix and GuixSD seems to
> still be in key developers' heads.

Noted.  We are actively working on improving our documentation and
looking for better ways of explaining Guix's core architecture.

Thanks,

- Dave