[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: question re. installing software & init system

From: Miles Fidelman
Subject: Re: question re. installing software & init system
Date: Fri, 1 Jan 2016 12:52:20 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

Thanks!  Some follow-ups inline, below....

On 12/31/15 5:41 PM, Thompson, David wrote:
Hello Miles,

On Thu, Dec 31, 2015 at 12:26 PM, Miles Fidelman
<address@hidden> wrote:
Hi Folks,

One thing that is very murky in the documentation is how to install software
that isn't packaged.  I can't seem to find any clear documentation on the
Packaging instructions can be found here:

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/.... ?

- 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"))
                   (list "mpd" "--no-daemon"(scope "mpd.conf"))))
        #:stop (make-kill-destructor))

The dmd manual can be found here:

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.

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.)

- 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.

And a general comment on the documentation:  Given that this is a (sort-of)
new distro, that does things VERY differently from previous distros - it
sure would be helpful to have the install documentation provide both a very
clear overview of the conceptual approach/architecture (vs. items spread
around various ppts)
We have a section dedicated to the features:

Are there any specific things that you would change about this section?

Well, yes. Including the referenced introduction, there's no elucidation of how Guix works, what scripts look like, how to write them, etc. Given that Guix is radically different than traditional package managers, a conceptual introduction seems important.

, AND very clear step-by-step instructions for:
- basic install & configuration

Very short, not a lot of details, particularly when compared to, say the Debian install instructions or the BSD handbook.

- installing & configuring packages (both those that run as services and
those that don't; including later re-configuration)

- installing & configuring software that isn't packaged
Linked earlier in the message.

- with particular attention to how the installer, package system, and init
system work together
- and with attention to how these all work with other build systems
You know - something like the Debian install instructions or the FreeBSD

Granted that documentation generally follows code; when doing things
radically differently, there's a lot to be said for writing documentation
FIRST - doing so provides a really good check on conceptual clarity and
usability.  (It kind of makes it hard to do any kind of testing, evaluating,
or contributing without a good starting point.)
In addition to all of the above-mentioned documentation sections, we
also have a contributing section:

Our documentation, like our code, is a work-in-progress.  We've been
building the manual alongside the code the entire time.  There is
certainly room for improvement, and we've been actively trying to
improve it, and we would *gladly* accept patches that clarify things
that tend to confuse new users.  That said, I think our documentation
is pretty decent and not so poor as you are describing.  We see more
and more contributors with each release, and the docs we do have
helped them get started.

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.

Miles Fidelman

In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

reply via email to

[Prev in Thread] Current Thread [Next in Thread]