From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Re: question re. installing software & init system Date: Thu, 31 Dec 2015 17:41:44 -0500 Message-ID: References: <56856545.8050104@meetinghouse.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36246) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aElul-0008N6-6y for help-guix@gnu.org; Thu, 31 Dec 2015 17:41:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aEluj-00077n-Oj for help-guix@gnu.org; Thu, 31 Dec 2015 17:41:47 -0500 Received: from mail-yk0-x231.google.com ([2607:f8b0:4002:c07::231]:32855) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEluj-00077W-H2 for help-guix@gnu.org; Thu, 31 Dec 2015 17:41:45 -0500 Received: by mail-yk0-x231.google.com with SMTP id k129so166554725yke.0 for ; Thu, 31 Dec 2015 14:41:45 -0800 (PST) In-Reply-To: <56856545.8050104@meetinghouse.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org To: Miles Fidelman Cc: help-guix@gnu.org Hello Miles, On Thu, Dec 31, 2015 at 12:26 PM, Miles Fidelman 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 > process. Packaging instructions can be found here: https://gnu.org/software/guix/manual/html_node/Defining-Packages.html#Defining-Packages > 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 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 #: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 > - 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? > 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: https://gnu.org/software/guix/manual/html_node/Features.html#Features Are there any specific things that you would change about this section? > , AND very clear step-by-step instructions for: > - basic install & configuration https://gnu.org/software/guix/manual/html_node/Binary-Installation.html#Binary-Installation https://gnu.org/software/guix/manual/html_node/System-Installation.html#System-Installation > - installing & configuring packages (both those that run as services and > those that don't; including later re-configuration) https://gnu.org/software/guix/manual/html_node/Invoking-guix-package.html#Invoking-guix-package https://gnu.org/software/guix/manual/html_node/System-Configuration.html#System-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 > handbook. > > 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: https://gnu.org/software/guix/manual/html_node/Contributing.html#Contributing 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. Thanks for the feedback, - Dave