GNU Guix 0.2 released

GNU Guix 0.2 released

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 6088 bytes --]

We are pleased to announce GNU Guix version 0.2, the second alpha
release, representing 580 commits by 5 people over 4 months.


• About

  GNU Guix is a functional package manager and distribution of
  the GNU system.

  In addition to standard package management features, Guix supports
  transactional upgrades and roll-backs, unprivileged package
  management, per-user profiles, and garbage collection.  Guix uses
  mechanisms from the Nix package management tool, with a Guile Scheme
  programming interface.

  http://www.gnu.org/software/guix/


• Download

  Here are the compressed sources and a GPG detached signature[*]:
    ftp://alpha.gnu.org/gnu/guix/guix-0.2.tar.gz
    ftp://alpha.gnu.org/gnu/guix/guix-0.2.tar.gz.sig

  Use a mirror for higher download bandwidth:
    http://www.gnu.org/order/ftp.html

  Here are the MD5 and SHA1 checksums:

  4bdbbd736d0bbcb6cd7e28220c4ea1fe  guix-0.2.tar.gz
  051a65d1d7aa9a0ea69fe97d6d9a8b93fe09cca0  guix-0.2.tar.gz

  [*] Use a .sig file to verify that the corresponding file (without the
  .sig suffix) is intact.  First, be sure to download both the .sig file
  and the corresponding tarball.  Then, run a command like this:

    gpg --verify guix-0.2.tar.gz.sig

  If that command fails because you don't have the required public key,
  then run this command to import it:

    gpg --keyserver keys.gnupg.net --recv-keys EA52ECF4

  and rerun the 'gpg --verify' command.

  This release was bootstrapped with the following tools:
    Autoconf 2.69
    Automake 1.13.1
    Makeinfo 5.1


• Changes since version 0.1 (excerpt from the NEWS file)

  ** Package management

  *** Guix commands are now sub-commands of the “guix” program

  Instead of typing “guix-package”, one now has to type “guix package”, and so
  on.  This has allowed us to homogenize the user interface and initial program
  setup, and to allow commands to be upgradable through “guix pull”.

  *** New “guix package --upgrade” option

  As the name implies, this option atomically upgrades all the packages
  installed in a profile or the set of packages matching a given regexp.
  See “Invoking guix package” in the manual.

  *** New “guix package --search” option

  Performs a full text search in package synopses and descriptions, and returns
  the matching packages in recutils format.  See “Invoking guix package” in the
  manual, for details.

  *** New “guix pull” command

  The command pulls the latest version of Guix–both the package management
  modules and the distribution.  See the manual for details.

  *** New binary substituter

  The “substituter” mechanism allows pre-built binaries to be transparently
  downloaded instead of performing a build locally.  Currently binaries are
  available for x86_64 Linux-based GNU systems from http://hydra.gnu.org.  The
  distribution is continuously built and binaries are made available from there.

  See http://hydra.gnu.org/jobset/gnu/master under “Job status” for the list of
  available binary packages.

  *** New “guix refresh” command

  The command is used by Guix maintainers.  It automatically updates the
  distribution to the latest upstream releases of GNU software.

  *** New “guix hash” command

  Convenience command to compute the hash of a file.  See the manual for
  details.

  *** Nix daemon code updated

  The daemon code from Nix, used by the ‘guix-daemon’ command, has been updated
  to current Nix ‘master’.

  ** Programming interfaces

  *** (guix download) now supports HTTPS, using GnuTLS

  It allows package source tarballs to be retrieved over HTTPS.

  *** New ‘native-search-path’ and ‘search-path’ package fields

  Packages can define in their ‘native-search-path’ field environment variables
  that define search paths and need to be set for proper functioning of the
  package.  For instance, GCC has ‘CPATH’ and ‘LIBRARY_PATH’ in its
  ‘native-search-path’, Perl has ‘PERL5LIB’, Python has ‘PYTHONPATH’, etc.
  These environment variables are automatically set when building a package that
  uses one of these.

  *** Package inputs can be a function of the target system type

  The ‘inputs’ field of a package can now be conditional on the value of
  (%current-system).  This is useful for packages that take system-dependent
  tarballs as inputs, such as GNU/MIT Scheme.

  *** New build systems

  The ‘perl-build-system’, ‘python-build-system’, and ‘cmake-build-system’ have
  been added.  They implement the standard build systems for Perl, Python, and
  CMake packages.

  *** Tools to build Linux initrds, QEMU images, and more

  The (gnu packages linux-initrd) module provides a procedure to build a Linux
  initrd (“initial RAM disk”).  The initrd embeds Guile, which is used to
  evaluate the given expression.  The example below returns an initrd that
  mounts the /proc file system and starts a REPL:

    (expression->initrd
      '(begin
         (mkdir "/proc")
         (mount "none" "/proc" "proc")
         ((@ (system repl repl) start-repl))))

  More examples in the linux-initrd.scm file.

  Experimental interfaces to produce and use QEMU images are provided by the
  (gnu system vm) module.  For instance, the
  ‘expression->derivation-in-linux-vm’ evaluates the given Scheme expression in
  a QEMU virtual machine running the Linux kernel and Guile.

  ** GNU distribution

  Many updates and additions have been made to the distribution.  Here are the
  highlights.

  *** Major updates

  GCC 4.7.3 (the default) and GCC 4.8.0, Binutils 2.23.2, Guile 2.0.9,
  Coreutils 8.20, GDB 7.6, Texinfo 5.1.

  *** Noteworthy new packages

  TeXLive, Xorg, GNU GRUB, GNU Parted, QEMU and QEMU-KVM, Avahi, Bigloo,
  CHICKEN, Scheme48, Hugs, Python, Lua, Samba.


Please report bugs to bug-guix@gnu.org.

Ludovic, on behalf of the Guix team.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: GNU Guix 0.2 released

[Xue Fuqiao]

On Mon, May 13, 2013 at 5:59 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> We are pleased to announce GNU Guix version 0.2, the second alpha
> release, representing 580 commits by 5 people over 4 months.

Great news, *thanks* to everyone involved!

> • About
>
>   GNU Guix is a functional package manager and distribution of
>   the GNU system.
>
>   In addition to standard package management features, Guix supports
>   transactional upgrades and roll-backs, unprivileged package
>   management, per-user profiles, and garbage collection.  Guix uses
>   mechanisms from the Nix package management tool, with a Guile Scheme
>   programming interface.
>
>   http://www.gnu.org/software/guix/
>
>
> • Download
>
>   Here are the compressed sources and a GPG detached signature[*]:
>     ftp://alpha.gnu.org/gnu/guix/guix-0.2.tar.gz
>     ftp://alpha.gnu.org/gnu/guix/guix-0.2.tar.gz.sig
>
>   Use a mirror for higher download bandwidth:
>     http://www.gnu.org/order/ftp.html
>
>   Here are the MD5 and SHA1 checksums:
>
>   4bdbbd736d0bbcb6cd7e28220c4ea1fe  guix-0.2.tar.gz
>   051a65d1d7aa9a0ea69fe97d6d9a8b93fe09cca0  guix-0.2.tar.gz
>
>   [*] Use a .sig file to verify that the corresponding file (without the
>   .sig suffix) is intact.  First, be sure to download both the .sig file
>   and the corresponding tarball.  Then, run a command like this:
>
>     gpg --verify guix-0.2.tar.gz.sig
>
>   If that command fails because you don't have the required public key,
>   then run this command to import it:
>
>     gpg --keyserver keys.gnupg.net --recv-keys EA52ECF4
>
>   and rerun the 'gpg --verify' command.
>
>   This release was bootstrapped with the following tools:
>     Autoconf 2.69
>     Automake 1.13.1
>     Makeinfo 5.1
>
>
> • Changes since version 0.1 (excerpt from the NEWS file)
>
>   ** Package management
>
>   *** Guix commands are now sub-commands of the “guix” program
>
>   Instead of typing “guix-package”, one now has to type “guix package”, and so
>   on.  This has allowed us to homogenize the user interface and initial program
>   setup, and to allow commands to be upgradable through “guix pull”.
>
>   *** New “guix package --upgrade” option
>
>   As the name implies, this option atomically upgrades all the packages
>   installed in a profile or the set of packages matching a given regexp.
>   See “Invoking guix package” in the manual.
>
>   *** New “guix package --search” option
>
>   Performs a full text search in package synopses and descriptions, and returns
>   the matching packages in recutils format.  See “Invoking guix package” in the
>   manual, for details.
>
>   *** New “guix pull” command
>
>   The command pulls the latest version of Guix–both the package management
>   modules and the distribution.  See the manual for details.
>
>   *** New binary substituter
>
>   The “substituter” mechanism allows pre-built binaries to be transparently
>   downloaded instead of performing a build locally.  Currently binaries are
>   available for x86_64 Linux-based GNU systems from http://hydra.gnu.org.  The
>   distribution is continuously built and binaries are made available from there.
>
>   See http://hydra.gnu.org/jobset/gnu/master under “Job status” for the list of
>   available binary packages.
>
>   *** New “guix refresh” command
>
>   The command is used by Guix maintainers.  It automatically updates the
>   distribution to the latest upstream releases of GNU software.
>
>   *** New “guix hash” command
>
>   Convenience command to compute the hash of a file.  See the manual for
>   details.
>
>   *** Nix daemon code updated
>
>   The daemon code from Nix, used by the ‘guix-daemon’ command, has been updated
>   to current Nix ‘master’.
>
>   ** Programming interfaces
>
>   *** (guix download) now supports HTTPS, using GnuTLS
>
>   It allows package source tarballs to be retrieved over HTTPS.
>
>   *** New ‘native-search-path’ and ‘search-path’ package fields
>
>   Packages can define in their ‘native-search-path’ field environment variables
>   that define search paths and need to be set for proper functioning of the
>   package.  For instance, GCC has ‘CPATH’ and ‘LIBRARY_PATH’ in its
>   ‘native-search-path’, Perl has ‘PERL5LIB’, Python has ‘PYTHONPATH’, etc.
>   These environment variables are automatically set when building a package that
>   uses one of these.
>
>   *** Package inputs can be a function of the target system type
>
>   The ‘inputs’ field of a package can now be conditional on the value of
>   (%current-system).  This is useful for packages that take system-dependent
>   tarballs as inputs, such as GNU/MIT Scheme.
>
>   *** New build systems
>
>   The ‘perl-build-system’, ‘python-build-system’, and ‘cmake-build-system’ have
>   been added.  They implement the standard build systems for Perl, Python, and
>   CMake packages.
>
>   *** Tools to build Linux initrds, QEMU images, and more
>
>   The (gnu packages linux-initrd) module provides a procedure to build a Linux
>   initrd (“initial RAM disk”).  The initrd embeds Guile, which is used to
>   evaluate the given expression.  The example below returns an initrd that
>   mounts the /proc file system and starts a REPL:
>
>     (expression->initrd
>       '(begin
>          (mkdir "/proc")
>          (mount "none" "/proc" "proc")
>          ((@ (system repl repl) start-repl))))
>
>   More examples in the linux-initrd.scm file.
>
>   Experimental interfaces to produce and use QEMU images are provided by the
>   (gnu system vm) module.  For instance, the
>   ‘expression->derivation-in-linux-vm’ evaluates the given Scheme expression in
>   a QEMU virtual machine running the Linux kernel and Guile.
>
>   ** GNU distribution
>
>   Many updates and additions have been made to the distribution.  Here are the
>   highlights.
>
>   *** Major updates
>
>   GCC 4.7.3 (the default) and GCC 4.8.0, Binutils 2.23.2, Guile 2.0.9,
>   Coreutils 8.20, GDB 7.6, Texinfo 5.1.
>
>   *** Noteworthy new packages
>
>   TeXLive, Xorg, GNU GRUB, GNU Parted, QEMU and QEMU-KVM, Avahi, Bigloo,
>   CHICKEN, Scheme48, Hugs, Python, Lua, Samba.
>
>
> Please report bugs to bug-guix@gnu.org.
>
> Ludovic, on behalf of the Guix team.

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Re: GNU Guix 0.2 released

[Germán Arias]

On 2013-05-13 17:12:07 -0600 Xue Fuqiao <xfq.free@gmail.com> wrote:

> On Mon, May 13, 2013 at 5:59 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>> We are pleased to announce GNU Guix version 0.2, the second alpha
>> release, representing 580 commits by 5 people over 4 months.
> 
> Great news, *thanks* to everyone involved!
> 

Currently I'm testing GSRC on my PC. So, my question is: What is the difference between Guix and GSRC? Regards.

Re: GNU Guix 0.2 released

[Xue Fuqiao]

On Wed, May 15, 2013 at 8:56 AM, Germán Arias <german@xelalug.org> wrote:
> On 2013-05-13 17:12:07 -0600 Xue Fuqiao <xfq.free@gmail.com> wrote:
>
>> On Mon, May 13, 2013 at 5:59 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> We are pleased to announce GNU Guix version 0.2, the second alpha
>>> release, representing 580 commits by 5 people over 4 months.
>>
>> Great news, *thanks* to everyone involved!
>>
>
> Currently I'm testing GSRC on my PC. So, my question is: What is the difference between Guix and GSRC? Regards.

IIUC GNU SRC is only a simple way to install the latest officially
released versions of _GNU_ packages.  GNU Guix is a purely functional
package manager for the GNU system, and the package in Guix is not
necessarily be a GNU program.

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Re: GNU Guix 0.2 released

[Ludovic Courtès]

Hi Germán,

Xue Fuqiao <xfq.free@gmail.com> skribis:

> On Wed, May 15, 2013 at 8:56 AM, Germán Arias <german@xelalug.org> wrote:
>> On 2013-05-13 17:12:07 -0600 Xue Fuqiao <xfq.free@gmail.com> wrote:
>>
>>> On Mon, May 13, 2013 at 5:59 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>>> We are pleased to announce GNU Guix version 0.2, the second alpha
>>>> release, representing 580 commits by 5 people over 4 months.
>>>
>>> Great news, *thanks* to everyone involved!
>>>
>>
>> Currently I'm testing GSRC on my PC. So, my question is: What is the difference between Guix and GSRC? Regards.
>
> IIUC GNU SRC is only a simple way to install the latest officially
> released versions of _GNU_ packages.  GNU Guix is a purely functional
> package manager for the GNU system, and the package in Guix is not
> necessarily be a GNU program.

Right.  So Guix is a package manager (like APT, but with additional
features), and GNU Guix comes with a GNU/Linux distribution (a small one
currently, but the goal is to have a complete distro.)

A feature that you may find useful for the purpose of testing GNUstep is
that several variants of the same package (for instance, GNUstep build
with different options, or different versions of its dependencies) can
coexist.  The system maintains a mapping between your package’s recipe
and its build result, so you know exactly what you’re testing.

Anyway, I’ve also been thinking that it’d be great to have GNUstep
packaged in Guix one of these days.  If you want to help with that, I’m
happy to give a hand!  :-)

Thanks,
Ludo’.

Re: GNU Guix 0.2 released

[Germán Arias]

On 2013-05-15 01:42:05 -0600 ludo@gnu.org (Ludovic Courtès wrote:
> 
> A feature that you may find useful for the purpose of testing GNUstep is
> that several variants of the same package (for instance, GNUstep build
> with different options, or different versions of its dependencies) can
> coexist.  The system maintains a mapping between your package’s recipe
> and its build result, so you know exactly what you’re testing.

Interesting.

> 
> Anyway, I’ve also been thinking that it’d be great to have GNUstep
> packaged in Guix one of these days.  If you want to help with that, I’m
> happy to give a hand!  :-)

I have read the documentation and conceptually it seems easy. But I guess
the hard part is the requirements, right?. If I have time I will give a try.

Regards.
Germán.

Re: GNU Guix 0.2 released

[Ludovic Courtès]

Germán Arias <german@xelalug.org> skribis:

> On 2013-05-15 01:42:05 -0600 ludo@gnu.org (Ludovic Courtès wrote:

[...]

>> Anyway, I’ve also been thinking that it’d be great to have GNUstep
>> packaged in Guix one of these days.  If you want to help with that, I’m
>> happy to give a hand!  :-)
>
> I have read the documentation and conceptually it seems easy. But I guess
> the hard part is the requirements, right?

It has a few dependencies, yes.  Let us know how it goes.

> If I have time I will give a try.

IIRC GNUstep packages don’t use the GNU build system (./configure &&
make), but rather gnustep-make, right?

If that is the case, a good way to help with GNUstep packaging would be
to implement a ‘gnustep-build-system’ embodying GNUstep’s build system
idioms.  That is a bit more involved, but I (or others here) can help.

Thanks,
Ludo’.

Re: GNU Guix 0.2 released

[German Arias]

2013/5/16, Ludovic Courtès <ludo@gnu.org>:
>
> IIRC GNUstep packages don’t use the GNU build system (./configure &&
> make), but rather gnustep-make, right?

The installation of gnustep packages (make, base, gui and back) is in the normal
way: ./configure, make & make install. The difference is that the last three
packages use gnustep-make instead of GNU make. But depending of the
configuration of gnustep's enviroment, the end user doesn't notice any
difference.
Because the name of gnustep-make tool is also "make". I don't know how the
system can deal two tools named "make". But I think the trick is in
the fact that
gnustep's packages use GNUmakefiles instead of makefiles.

The only difference is that if the system don't know about the gnustep
tools. The
user will need run the gnustep script, something like ".
/usr/.../GNUstep.sh", to set
up the variables of gnustep environment.

The rest of packages is other history. Many of them only use: make &
make install.
Here "make" is "gnustep-make", And with the apps made with gnustep, as far as I
remember, only GWorkspace uses ./configure.

>
> If that is the case, a good way to help with GNUstep packaging would be
> to implement a ‘gnustep-build-system’ embodying GNUstep’s build system
> idioms.  That is a bit more involved, but I (or others here) can help.
>
> Thanks,
> Ludo’.
>

Germán.

Re: GNU Guix 0.2 released

[Ludovic Courtès]

German Arias <german@xelalug.org> skribis:

> 2013/5/16, Ludovic Courtès <ludo@gnu.org>:
>>
>> IIRC GNUstep packages don’t use the GNU build system (./configure &&
>> make), but rather gnustep-make, right?
>
> The installation of gnustep packages (make, base, gui and back) is in the normal
> way: ./configure, make & make install. The difference is that the last three
> packages use gnustep-make instead of GNU make. But depending of the
> configuration of gnustep's enviroment, the end user doesn't notice any
> difference.

OK.

> Because the name of gnustep-make tool is also "make". I don't know how the
> system can deal two tools named "make". But I think the trick is in
> the fact that
> gnustep's packages use GNUmakefiles instead of makefiles.

The two ‘make’ programs shouldn’t be a problem.  ‘gnustep-make’ just
needs to be added as an input, and it will appear before GNU make in
$PATH.

> The only difference is that if the system don't know about the gnustep
> tools. The
> user will need run the gnustep script, something like ".
> /usr/.../GNUstep.sh", to set
> up the variables of gnustep environment.

What do you mean with “doesn’t know about the GNUstep tools”?  When is
it necessary to source that script?  What are the variables to be
defined?

Guix has a mechanism to automatically define search path variables:

  http://lists.gnu.org/archive/html/bug-guix/2013-03/msg00158.html

Would that be of any help?

> The rest of packages is other history. Many of them only use: make &
> make install.
> Here "make" is "gnustep-make",

For those, it may make sense to implement a specific build system that
automatically adds ‘gnustep-make’ as an input and runs the right
commands.

Thanks,
Ludo’.

Re: GNU Guix 0.2 released

[Germán Arias]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

On 2013-05-17 07:27:10 -0600 ludo@gnu.org (Ludovic Courtès wrote:
[snip]
> 
>> The only difference is that if the system don't know about the gnustep
>> tools. The
>> user will need run the gnustep script, something like ".
>> /usr/.../GNUstep.sh", to set
>> up the variables of gnustep environment.
> 
> What do you mean with “doesn’t know about the GNUstep tools”?  When is
> it necessary to source that script?  What are the variables to be
> defined?

GNUstep can be installed using differents layouts. By default gnustep is
installed using the FHS layout. But one popular layout is "gnustep", this
install all in "/usr/GNUstep". Since this isn't an standard path to install
libraries, headers and tools, the user need add this path or run the
gnustep script at session startup or run it when he will use the
gnustep-make tool.

> 
> Guix has a mechanism to automatically define search path variables:
> 
>   http://lists.gnu.org/archive/html/bug-guix/2013-03/msg00158.html
> 
> Would that be of any help?

I think it can help. Although I'm not an expert in what does exactly
the gnustep script. I send you it attached if you want take a look.
Anyway, installing gnustep with FHS layout, avoids the use of
this script.

> 
>> The rest of packages is other history. Many of them only use: make &
>> make install.
>> Here "make" is "gnustep-make",
> 
> For those, it may make sense to implement a specific build system that
> automatically adds ‘gnustep-make’ as an input and runs the right
> commands.
> 
> Thanks,
> Ludo’.
> 

<GNUstep.sh>



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: GNUstep.sh --]
[-- Type: text/x-sh; name="GNUstep.sh", Size: 22607 bytes --]

#   This file must be sourced inside (ba)sh using: .
#
#   GNUstep.sh.  Generated from GNUstep.sh.in by configure.
#
#   Shell initialization for the GNUstep environment.
#
#   Copyright (C) 1997-2008 Free Software Foundation, Inc.
#
#   Author:  Scott Christley <scottc@net-community.com>
#   Author:  Adam Fedor <fedor@gnu.org>
#   Author:  Richard Frith-Macdonald <rfm@gnu.org>
#   Author:  Nicola Pero <nicola.pero@meta-innovation.com>
#
#   This file is part of the GNUstep Makefile Package.
#
#   This library is free software; you can redistribute it and/or
#   modify it under the terms of the GNU General Public License
#   as published by the Free Software Foundation; either version 3
#   of the License, or (at your option) any later version.
#   
#   You should have received a copy of the GNU General Public
#   License along with this library; see the file COPYING.
#   If not, write to the Free Software Foundation,
#   51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
#

# Warning - this shell script is delicate, because it is sourced by
# using . rather than simply executed.  It is sourced because that is
# the only way to change the shell variables in the calling
# environment.
#
# Sourcing makes the shell script more delicate for the following reasons:
#
#  * temporary variables are automatically set in the calling
#  environment!  WORKAROUND: we need to unset all them after using
#  them to avoid polluting the calling environment;
#
#  * not only the exit value of the script, but the exit value of each
#  command we execute, might be interpreted by the calling
#  environment.  Typically, the calling environment might be using the
#  shell errexit option ('set -e') in bash parlance, which causes the
#  shell to exit if any command returns an error value.  If this were
#  a normal script, this option would mean that the shell would exit
#  if the return value of the whole script were an error value; but
#  because we are sourced, it is as all the commands in this script
#  were executed directly in the calling environment, so *all* values
#  returned by *all* commands must be non-error.  [this all typically
#  happens in rpm builds, where scripts are run with the errexit
#  option so that errors in scripts abort the build, and now if a
#  script sources GNUstep.sh, then we are exactly in this situation -
#  if any command inside GNUstep.sh returns an error value (even if
#  GNUstep.sh as a whole would be happy and return succes), the whole
#  rpm build process aborts!]. WORKAROUND: we must make sure all
#  commands return success - last resorts hacks like 'command || :'
#  which always returns success whatever command returns.
#

# If we're running in zsh (auch!) make sure we're using -y
# (SH_WORD_SPLIT) else our path manipulations won't work.
if [ -n "$ZSH_VERSION" ]; then

  # If -y is not already set, set it and remember that we
  # need to set it back to what it was at the end.
  if ( setopt | grep shwordsplit > /dev/null ); then :; else
    setopt shwordsplit
    GS_ZSH_NEED_TO_RESTORE_SET=yes
  fi

fi

# When this is set to 'yes', strict gnustep-make v2 compatibility mode
# is turned on.
GNUSTEP_MAKE_STRICT_V2_MODE=no

#
# Read our configuration files
#

# Determine the location of the system configuration file
if [ -z "$GNUSTEP_CONFIG_FILE" ]; then
  GNUSTEP_CONFIG_FILE=/etc/GNUstep/GNUstep.conf
else
  # Remember that the variable was already set in the environment, and
  # preserve it at the end of the script.  Otherwise we'll unset it to
  # avoid polluting the environment with our own internal variables.
  GNUSTEP_KEEP_CONFIG_FILE=yes
fi

# Determine the location of the user configuration file
if [ -z "$GNUSTEP_USER_CONFIG_FILE" ]; then
  GNUSTEP_USER_CONFIG_FILE=.GNUstep.conf
else
  GNUSTEP_KEEP_USER_CONFIG_FILE=yes
fi

# Read the system configuration file
if [ -f "$GNUSTEP_CONFIG_FILE" ]; then
  . "$GNUSTEP_CONFIG_FILE"
fi

# FIXME: determining GNUSTEP_HOME
GNUSTEP_HOME=~

# Read the user configuration file ... unless it is disabled (ie, set
# to an empty string)
if [ -n "$GNUSTEP_USER_CONFIG_FILE" ]; then
  case "$GNUSTEP_USER_CONFIG_FILE" in 
    /*) # An absolute path
        if [ -f "$GNUSTEP_USER_CONFIG_FILE" ]; then
          . "$GNUSTEP_USER_CONFIG_FILE"
        fi;;
     *) # Something else
        if [ -f "$GNUSTEP_HOME/$GNUSTEP_USER_CONFIG_FILE" ]; then
          . "$GNUSTEP_HOME/$GNUSTEP_USER_CONFIG_FILE"
        fi;;
  esac
fi

# Now, set any essential variable (that is not already set) to the
# built-in values.

if [ "$GNUSTEP_MAKE_STRICT_V2_MODE" = "yes" ]; then
  # In strict v2 mode, clean these obsolete variables in case the
  # config file contains them.  They shouldn't exist so unsetting
  # them can't harm.
  unset GNUSTEP_SYSTEM_ROOT
  unset GNUSTEP_LOCAL_ROOT
  unset GNUSTEP_NETWORK_ROOT
else
  # This is deprecated and will be removed
  if [ -z "$GNUSTEP_SYSTEM_ROOT" ]; then
    GNUSTEP_SYSTEM_ROOT=/usr/GNUstep/System
  fi

  # This is deprecated and will be removed
  if [ -z "$GNUSTEP_LOCAL_ROOT" ]; then
    GNUSTEP_LOCAL_ROOT=/usr/GNUstep/Local
  fi

  # This is deprecated and will be removed
  if [ -z "$GNUSTEP_NETWORK_ROOT" ]; then
    GNUSTEP_NETWORK_ROOT=/usr/GNUstep/Network
  fi

  export GNUSTEP_SYSTEM_ROOT GNUSTEP_LOCAL_ROOT GNUSTEP_NETWORK_ROOT
fi

# GNUSTEP_FLATTENED is obsolete, please use GNUSTEP_IS_FLATTENED
# instead
if [ "$GNUSTEP_MAKE_STRICT_V2_MODE" = "yes" ]; then
  unset GNUSTEP_FLATTENED
else
  GNUSTEP_FLATTENED=yes
  export GNUSTEP_FLATTENED
fi
GNUSTEP_IS_FLATTENED=yes
if [ -z "$LIBRARY_COMBO" ]; then
  LIBRARY_COMBO=gnu-gnu-gnu
fi
if [ ! "$GNUSTEP_MAKE_STRICT_V2_MODE" = "yes" ]; then
  # Having these variables in the environment is deprecated and will
  # be removed.  But for now, if we are not in strict gnustep-make v2
  # mode, then we always export these variables for
  # backwards-compatibility.
  export GNUSTEP_IS_FLATTENED LIBRARY_COMBO

  # Else they are only exported if GNUSTEP_SH_EXPORT_ALL_VARIABLES
  # is defined - at the end of the script.
fi

if [ -z "$GNUSTEP_MAKEFILES" ]; then
  GNUSTEP_MAKEFILES=/usr/GNUstep/System/Library/Makefiles
fi
export GNUSTEP_MAKEFILES


if [ "$GNUSTEP_MAKE_STRICT_V2_MODE" = "yes" ]; then
  # Make sure this is never set in gnustep-make v2 strict mode; it
  # might have been set in the config file.
  unset GNUSTEP_USER_DIR
  unset GNUSTEP_USER_ROOT
else
  # GNUSTEP_USER_DIR is deprecated and will be removed
  if [ -z "$GNUSTEP_USER_DIR" ]; then
    GNUSTEP_USER_DIR=GNUstep
  fi

  #
  # Set GNUSTEP_USER_ROOT which is the variable used in practice.
  # GNUSTEP_USER_ROOT is deprecated and will be removed
  #
  case "$GNUSTEP_USER_DIR" in 
    /*) # An absolute path
        GNUSTEP_USER_ROOT="$GNUSTEP_USER_DIR";;
     *) # Something else
        GNUSTEP_USER_ROOT="$GNUSTEP_HOME/$GNUSTEP_USER_DIR";;
  esac

  # This variable was used to set up GNUSTEP_USER_ROOT which is the one
  # that is actually exported; we can now drop it from the environment.
  unset GNUSTEP_USER_DIR

  # This is deprecated and will be removed
  export GNUSTEP_USER_ROOT
fi

# If multi-platform support is disabled, just use the hardcoded cpu,
# vendor and os determined when gnustep-make was configured.  The
# reason using the hardcoded ones might be better is that config.guess
# and similar scripts might even require compiling test files to
# determine the platform - but then you can't source GNUstep.sh
# without having gcc, binutils, libc6-dev installed.  Which can be a
# problem for end-users who are not developers and have no development
# tools installed.  To prevent this problem, unless we were configured
# to determine the platform at run time, by default we use the
# hardcoded values of GNUSTEP_HOST*.
if [ -z "" ]; then
  GNUSTEP_HOST=i686-pc-linux-gnu
  GNUSTEP_HOST_CPU=ix86
  GNUSTEP_HOST_VENDOR=pc
  GNUSTEP_HOST_OS=linux-gnu
fi

#
# Determine the host information
#
if [ -z "$GNUSTEP_HOST" ]; then
  # Not all shells (e.g. /bin/sh on FreeBSD < 4.0 or ash) have pushd/popd
  tmpdir=`pwd`; cd /tmp
  GNUSTEP_HOST=`$GNUSTEP_MAKEFILES/config.guess`
  GNUSTEP_HOST=`$GNUSTEP_MAKEFILES/config.sub $GNUSTEP_HOST`
  cd "$tmpdir"
  unset tmpdir
fi

if [ -z "$GNUSTEP_HOST_CPU" ]; then
  GNUSTEP_HOST_CPU=`$GNUSTEP_MAKEFILES/cpu.sh $GNUSTEP_HOST`
  GNUSTEP_HOST_CPU=`$GNUSTEP_MAKEFILES/clean_cpu.sh $GNUSTEP_HOST_CPU`
fi

if [ -z "$GNUSTEP_HOST_VENDOR" ]; then
  GNUSTEP_HOST_VENDOR=`$GNUSTEP_MAKEFILES/vendor.sh $GNUSTEP_HOST`
  GNUSTEP_HOST_VENDOR=`$GNUSTEP_MAKEFILES/clean_vendor.sh $GNUSTEP_HOST_VENDOR`
fi

if [ -z "$GNUSTEP_HOST_OS" ]; then 
  GNUSTEP_HOST_OS=`$GNUSTEP_MAKEFILES/os.sh $GNUSTEP_HOST`
  GNUSTEP_HOST_OS=`$GNUSTEP_MAKEFILES/clean_os.sh $GNUSTEP_HOST_OS`
fi

if [ ! "$GNUSTEP_MAKE_STRICT_V2_MODE" = "yes" ]; then
  # These variables are deprecated for usage in shell scripts; you
  # need to use gnustep-config to get them in a shell script.
  export GNUSTEP_HOST GNUSTEP_HOST_CPU GNUSTEP_HOST_VENDOR GNUSTEP_HOST_OS

  # Even in strict gnustep-make v2 mode, we export them at the end
  # if explicitly requested to export all variables.
fi

# Now load in all the remaining paths
. $GNUSTEP_MAKEFILES/filesystem.sh

# No longer needed
unset GNUSTEP_HOME

# Determine if the paths look like Windows paths that need fixing
fixup_paths=no
# Here we want to use `...` but the only portable way to use it when
# there are "..." inside the expression (ie, it's actually
# `..."..."...`) seems to be to use it in variable assignments.  So we
# use a temporary variable and assign the result of `...` to it
path_check=`echo "$GNUSTEP_MAKEFILES" | sed 's|^[a-zA-Z]:/.*$||'`
if [ -z "$path_check" ]; then
  fixup_paths=yes
fi
unset path_check

if [ "$GNUSTEP_MAKE_STRICT_V2_MODE" = "yes" ]; then
  unset GNUSTEP_PATHLIST
else
  # GNUSTEP_PATHLIST is deprecated and will be removed.
  #
  # GNUSTEP_PATHLIST is like an abstract path-like shell variable, which
  # can be used to search the gnustep directories.
  #
  if [ -z "$GNUSTEP_PATHLIST" ]; then

   GNUSTEP_PATHLIST=`$GNUSTEP_MAKEFILES/print_unique_pathlist.sh "$GNUSTEP_USER_ROOT" "$GNUSTEP_LOCAL_ROOT" "$GNUSTEP_NETWORK_ROOT" "$GNUSTEP_SYSTEM_ROOT" $fixup_paths`
   export GNUSTEP_PATHLIST
  fi
fi

#
# Add path to Tools to PATH
#
# NB: functionally, print_unique_pathlist.sh is mostly used to do the
# fixup_paths thing, since duplicated paths will automatically be
# checked below when we add them to the PATH.  On the other hand,
# removing duplicates later can be expensive since we do a echo+grep
# for each duplicate.  When there are many duplicates it's faster to
# use print_unique_pathlist.sh first to remove them and skip the
# echos+greps later.
GNUSTEP_TOOLS_PATHLIST=`$GNUSTEP_MAKEFILES/print_unique_pathlist.sh "$GNUSTEP_USER_TOOLS" "$GNUSTEP_LOCAL_TOOLS" "$GNUSTEP_NETWORK_TOOLS" "$GNUSTEP_SYSTEM_TOOLS" $fixup_paths`

# Now, we check the paths in GNUSTEP_*_ADMIN_TOOLS.  These paths
# should only be used by Administrators -- normal users don't have
# enough powers to use those tools to do useful things.  Our test for
# being an 'Administrator' is that anyone who can write to an Admin
# directory can be considered powerful enough to use those tools.

# FIXME: Unfortunately, this doesn't work if the Admin directory
# is mounted read-only, so a better test is required!

# So we examine GNUSTEP_*_ADMIN_TOOLS; if we find any path in that
# list that exists and that we can write to, we add it to our PATH.
for dir in "$GNUSTEP_SYSTEM_ADMIN_TOOLS" "$GNUSTEP_NETWORK_ADMIN_TOOLS" "$GNUSTEP_LOCAL_ADMIN_TOOLS" "$GNUSTEP_USER_ADMIN_TOOLS"; do
  if [ -d "$dir"  -a  -w "$dir" ]; then
    # Only add the new dir if it's not already in GNUSTEP_TOOLS_PATHLIST
    if (echo ":${GNUSTEP_TOOLS_PATHLIST}:" \
      |grep -v ":${dir}:" >/dev/null); then
      GNUSTEP_TOOLS_PATHLIST="$dir:$GNUSTEP_TOOLS_PATHLIST"
    fi
  fi
done

#
# And now, we put the results into PATH
#
old_IFS="$IFS"
IFS=:
for dir in $GNUSTEP_TOOLS_PATHLIST; do

  # Prepare the path_fragment
  if [ "$GNUSTEP_IS_FLATTENED" = "no" ]; then
    path_fragment="$dir:$dir/${GNUSTEP_HOST_CPU}/${GNUSTEP_HOST_OS}/${LIBRARY_COMBO}:$dir/${GNUSTEP_HOST_CPU}/${GNUSTEP_HOST_OS}"
  else
    path_fragment="$dir"
  fi

  # Add it to PATH, but only if not already there (eg, typically /usr/bin is already there)
  if [ -z "$PATH" ]; then
    PATH="$path_fragment"
  else
    if ( echo ":${PATH}:"\
      |grep -v ":${path_fragment}:" >/dev/null ); then
      PATH="${path_fragment}:${PATH}"
    fi
  fi

done
IFS="$old_IFS"
unset old_IFS
unset dir
unset path_fragment
unset GNUSTEP_TOOLS_PATHLIST
export PATH

# Determine the library paths
GNUSTEP_LIBRARIES_PATHLIST=`$GNUSTEP_MAKEFILES/print_unique_pathlist.sh "$GNUSTEP_USER_LIBRARIES" "$GNUSTEP_LOCAL_LIBRARIES" "$GNUSTEP_NETWORK_LIBRARIES" "$GNUSTEP_SYSTEM_LIBRARIES" $fixup_paths`

old_IFS="$IFS"
IFS=:
  for dir in $GNUSTEP_LIBRARIES_PATHLIST; do

    # prepare the path_fragment for libraries and this dir
    if [ "$GNUSTEP_IS_FLATTENED" = "yes" ]; then
      path_fragment="$dir"
    else
      path_fragment="$dir/$GNUSTEP_HOST_CPU/$GNUSTEP_HOST_OS/$LIBRARY_COMBO:$dir/$GNUSTEP_HOST_CPU/$GNUSTEP_HOST_OS"
    fi

    # Append the path_fragment to lib_paths ... in a different way,
    # depending on the machine we're on.
    case "$GNUSTEP_HOST_OS" in

      *nextstep4* | *darwin*)
        if [ -z "$DYLD_LIBRARY_PATH" ]; then
          DYLD_LIBRARY_PATH="$path_fragment"
        else
          if ( echo ":${DYLD_LIBRARY_PATH}:"\
	    |grep -v ":${path_fragment}:" >/dev/null ); then
	    DYLD_LIBRARY_PATH="$path_fragment:$DYLD_LIBRARY_PATH"
          fi
        fi
        export DYLD_LIBRARY_PATH;;

      *hpux*)
        if [ -z "$SHLIB_PATH" ]; then
          SHLIB_PATH="$path_fragment"
        else
          if ( echo ":${SHLIB_PATH}:"\
	    |grep -v ":${path_fragment}:" >/dev/null ); then
	    SHLIB_PATH="$path_fragment:$SHLIB_PATH"
          fi
        fi
        export SHLIB_PATH;

        if [ -z "$LD_LIBRARY_PATH" ]; then
          LD_LIBRARY_PATH="$path_fragment"
        else
          if ( echo ":${LD_LIBRARY_PATH}:"\
	    |grep -v ":${path_fragment}:" >/dev/null ); then
	    LD_LIBRARY_PATH="$path_fragment:$LD_LIBRARY_PATH"
          fi
        fi
        export LD_LIBRARY_PATH;;

      *)
        if [ -z "$LD_LIBRARY_PATH" ]; then
          LD_LIBRARY_PATH="$path_fragment"
        else
          if ( echo ":${LD_LIBRARY_PATH}:"\
	    |grep -v ":${path_fragment}:" >/dev/null ); then
	    LD_LIBRARY_PATH="$path_fragment:$LD_LIBRARY_PATH"
          fi
        fi
        export LD_LIBRARY_PATH;;
    esac
  done
IFS="$old_IFS"
unset old_IFS
unset dir
unset path_fragment

unset GNUSTEP_LIBRARIES_PATHLIST


# Determine the framework paths - but only on Darwin since it's the
# only platform where this is of any use.
case "$GNUSTEP_HOST_OS" in

  *darwin*)
    GNUSTEP_FRAMEWORKS_PATHLIST=`$GNUSTEP_MAKEFILES/print_unique_pathlist.sh "$GNUSTEP_USER_LIBRARY/Frameworks" "$GNUSTEP_LOCAL_LIBRARY/Frameworks" "$GNUSTEP_NETWORK_LIBRARY/Frameworks" "$GNUSTEP_SYSTEM_LIBRARY/Frameworks" $fixup_paths`

    old_IFS="$IFS"
    IFS=:
    for dir in $GNUSTEP_FRAMEWORKS_PATHLIST; do

      # prepare the path_fragment for frameworks
      path_fragment="$dir"

# The code below has been temporarily removed, because...
# Frameworks in GNUstep-make are supported by creating a link like
# 
#   Libraries/libMyFramework.dylib ->
#      Frameworks/MyFramework.framework/Versions/Current/libMyFramework.dylib,
#
# to mitigate the fact that FSF GCC does not support a -framework flag.
#
# On Darwin, however, we partially emulate -framework by setting the
# "install_name" to the framework name during linking. The dynamic
# linker (dyld) is smart enough to find the framework under this name,
# but only if DYLD_FRAMEWORK_PATH is set (unless we set the
# "install_name" to an absolute path, which we don't). We'd really like
# to fully support -framework, though.
#
# Use otool -L MyApplication.app/MyApplication, for instance, to see
# how the shared libraries/frameworks are linked.
#
#    if [ "$LIBRARY_COMBO" = "apple-apple-apple" -o \
#         "$LIBRARY_COMBO" = "apple" ]; then
    
      if [ -z "$DYLD_FRAMEWORK_PATH" ]; then
        DYLD_FRAMEWORK_PATH="$path_fragment"
      else
        if ( echo ":${DYLD_FRAMEWORK_PATH}:"\
	  |grep -v ":${path_fragment}:" >/dev/null ); then
          DYLD_FRAMEWORK_PATH="$path_fragment:$DYLD_FRAMEWORK_PATH"
        fi
      fi
      export DYLD_FRAMEWORK_PATH
    done

    IFS="$old_IFS"
    unset old_IFS
    unset dir
    unset path_fragment

    unset GNUSTEP_FRAMEWORKS_PATHLIST
    ;;

  *)
    ;;
esac

#
# Setup Java CLASSPATH and Guile GUILE_LOAD_PATH
#
GNUSTEP_LIBRARY_PATHLIST=`$GNUSTEP_MAKEFILES/print_unique_pathlist.sh "$GNUSTEP_USER_LIBRARY" "$GNUSTEP_LOCAL_LIBRARY" "$GNUSTEP_NETWORK_LIBRARY" "$GNUSTEP_SYSTEM_LIBRARY" $fixup_paths`

old_IFS="$IFS"
IFS=:
for dir in $GNUSTEP_LIBRARY_PATHLIST; do

  path_fragment="$dir/Libraries/Java"
  if [ -z "$CLASSPATH" ]; then
    CLASSPATH="$path_fragment"
  else
    if ( echo ":${CLASSPATH}:"\
      |grep -v ":${path_fragment}:" >/dev/null ); then
      CLASSPATH="$path_fragment:$CLASSPATH"
    fi
  fi

  path_fragment="$dir/Libraries/Guile"
  if [ -z "$GUILE_LOAD_PATH" ]; then
    GUILE_LOAD_PATH="$path_fragment"
  else
    if ( echo ":${GUILE_LOAD_PATH}:"\
      |grep -v ":${path_fragment}:" >/dev/null ); then
      GUILE_LOAD_PATH="$path_fragment:$GUILE_LOAD_PATH"
    fi
  fi

done
IFS="$old_IFS"
unset old_IFS
unset dir
unset path_fragment
unset GNUSTEP_LIBRARY_PATHLIST
export CLASSPATH
export GUILE_LOAD_PATH

#
# Make sure info files, that we install by default into
# xxx/Library/Documentation/info, are found by the info browsing
# programs.  To get this effect, we add those paths to INFOPATH.
#
GNUSTEP_INFO_PATHLIST=`$GNUSTEP_MAKEFILES/print_unique_pathlist.sh "$GNUSTEP_USER_DOC_INFO" "$GNUSTEP_LOCAL_DOC_INFO" "$GNUSTEP_NETWORK_DOC_INFO" "$GNUSTEP_SYSTEM_DOC_INFO" $fixup_paths`
old_IFS="$IFS"
IFS=:
for dir in $GNUSTEP_INFO_PATHLIST; do

  if [ -z "$INFOPATH" ]; then
    # The ':' at the end means to use the built-in paths after searching
    # the INFOPATH we provide.
    INFOPATH="${dir}:"
  else
    if ( echo ":${INFOPATH}:"\
      |grep -v ":${dir}:" >/dev/null ); then
      INFOPATH="$INFOPATH:${dir}:"
    fi
  fi
done
IFS="$old_IFS"
unset old_IFS
unset dir
unset GNUSTEP_INFO_PATHLIST
export INFOPATH

#
# Clean up the environment by removing the filesystem variables.  Do
# it unless we were explicitly requested not to clean it up!  Mostly
# gnustep-config will request that the environment is not cleaned up,
# so it can print out all of the GNUstep variables.
#
if [ -n "$GNUSTEP_SH_EXPORT_ALL_VARIABLES" ]; then
  export GNUSTEP_MAKE_STRICT_V2_MODE

  unset GNUSTEP_KEEP_CONFIG_FILE GNUSTEP_KEEP_USER_CONFIG_FILE

  export GNUSTEP_CONFIG_FILE GNUSTEP_USER_CONFIG_FILE

  export GNUSTEP_USER_DEFAULTS_DIR

  # Always export these variables even if in strict gnustep-make v2
  # mode, so that for example gnustep-config can determine them.
  export GNUSTEP_IS_FLATTENED LIBRARY_COMBO
  export GNUSTEP_HOST GNUSTEP_HOST_CPU GNUSTEP_HOST_VENDOR GNUSTEP_HOST_OS

  export GNUSTEP_SYSTEM_APPS GNUSTEP_SYSTEM_ADMIN_APPS GNUSTEP_SYSTEM_WEB_APPS GNUSTEP_SYSTEM_TOOLS GNUSTEP_SYSTEM_ADMIN_TOOLS 
  export GNUSTEP_SYSTEM_LIBRARY GNUSTEP_SYSTEM_HEADERS GNUSTEP_SYSTEM_LIBRARIES
  export GNUSTEP_SYSTEM_DOC GNUSTEP_SYSTEM_DOC_MAN GNUSTEP_SYSTEM_DOC_INFO

  export GNUSTEP_NETWORK_APPS GNUSTEP_NETWORK_ADMIN_APPS GNUSTEP_NETWORK_WEB_APPS GNUSTEP_NETWORK_TOOLS GNUSTEP_NETWORK_ADMIN_TOOLS 
  export GNUSTEP_NETWORK_LIBRARY GNUSTEP_NETWORK_HEADERS GNUSTEP_NETWORK_LIBRARIES
  export GNUSTEP_NETWORK_DOC GNUSTEP_NETWORK_DOC_MAN GNUSTEP_NETWORK_DOC_INFO

  export GNUSTEP_LOCAL_APPS GNUSTEP_LOCAL_ADMIN_APPS GNUSTEP_LOCAL_WEB_APPS GNUSTEP_LOCAL_TOOLS GNUSTEP_LOCAL_ADMIN_TOOLS 
  export GNUSTEP_LOCAL_LIBRARY GNUSTEP_LOCAL_HEADERS GNUSTEP_LOCAL_LIBRARIES
  export GNUSTEP_LOCAL_DOC GNUSTEP_LOCAL_DOC_MAN GNUSTEP_LOCAL_DOC_INFO

  export GNUSTEP_USER_APPS GNUSTEP_USER_ADMIN_APPS GNUSTEP_USER_WEB_APPS GNUSTEP_USER_TOOLS GNUSTEP_USER_ADMIN_TOOLS 
  export GNUSTEP_USER_LIBRARY GNUSTEP_USER_HEADERS GNUSTEP_USER_LIBRARIES
  export GNUSTEP_USER_DOC GNUSTEP_USER_DOC_MAN GNUSTEP_USER_DOC_INFO

  export GNUSTEP_SYSTEM_USERS_DIR GNUSTEP_LOCAL_USERS_DIR GNUSTEP_NETWORK_USERS_DIR
else
  if [ "$GNUSTEP_MAKE_STRICT_V2_MODE" = "yes" ]; then
    unset GNUSTEP_IS_FLATTENED
    unset LIBRARY_COMBO
    unset GNUSTEP_HOST
    unset GNUSTEP_HOST_CPU
    unset GNUSTEP_HOST_VENDOR
    unset GNUSTEP_HOST_OS
  fi

  unset GNUSTEP_MAKE_STRICT_V2_MODE

  # Unset these variables but only if we set them internally; keep
  # them if they were already in the environment.
  if [ -z "$GNUSTEP_KEEP_CONFIG_FILE" ]; then
    unset GNUSTEP_CONFIG_FILE
  fi
  unset GNUSTEP_KEEP_CONFIG_FILE 

  if [ -z "$GNUSTEP_KEEP_USER_CONFIG_FILE" ]; then
    unset GNUSTEP_USER_CONFIG_FILE
  fi
  unset GNUSTEP_KEEP_USER_CONFIG_FILE

  # Always unset these variables
  unset GNUSTEP_USER_DEFAULTS_DIR

  unset GNUSTEP_SYSTEM_APPS 
  unset GNUSTEP_SYSTEM_ADMIN_APPS 
  unset GNUSTEP_SYSTEM_WEB_APPS 
  unset GNUSTEP_SYSTEM_TOOLS 
  unset GNUSTEP_SYSTEM_ADMIN_TOOLS 
  unset GNUSTEP_SYSTEM_LIBRARY
  unset GNUSTEP_SYSTEM_HEADERS 
  unset GNUSTEP_SYSTEM_LIBRARIES 
  unset GNUSTEP_SYSTEM_DOC 
  unset GNUSTEP_SYSTEM_DOC_MAN
  unset GNUSTEP_SYSTEM_DOC_INFO

  unset GNUSTEP_NETWORK_APPS 
  unset GNUSTEP_NETWORK_ADMIN_APPS 
  unset GNUSTEP_NETWORK_WEB_APPS 
  unset GNUSTEP_NETWORK_TOOLS 
  unset GNUSTEP_NETWORK_ADMIN_TOOLS 
  unset GNUSTEP_NETWORK_LIBRARY
  unset GNUSTEP_NETWORK_HEADERS 
  unset GNUSTEP_NETWORK_LIBRARIES 
  unset GNUSTEP_NETWORK_DOC 
  unset GNUSTEP_NETWORK_DOC_MAN
  unset GNUSTEP_NETWORK_DOC_INFO

  unset GNUSTEP_LOCAL_APPS 
  unset GNUSTEP_LOCAL_ADMIN_APPS 
  unset GNUSTEP_LOCAL_WEB_APPS 
  unset GNUSTEP_LOCAL_TOOLS 
  unset GNUSTEP_LOCAL_ADMIN_TOOLS 
  unset GNUSTEP_LOCAL_LIBRARY
  unset GNUSTEP_LOCAL_HEADERS 
  unset GNUSTEP_LOCAL_LIBRARIES 
  unset GNUSTEP_LOCAL_DOC 
  unset GNUSTEP_LOCAL_DOC_MAN
  unset GNUSTEP_LOCAL_DOC_INFO

  unset GNUSTEP_USER_APPS 
  unset GNUSTEP_USER_ADMIN_APPS 
  unset GNUSTEP_USER_WEB_APPS 
  unset GNUSTEP_USER_TOOLS 
  unset GNUSTEP_USER_ADMIN_TOOLS 
  unset GNUSTEP_USER_LIBRARY
  unset GNUSTEP_USER_HEADERS 
  unset GNUSTEP_USER_LIBRARIES 
  unset GNUSTEP_USER_DOC 
  unset GNUSTEP_USER_DOC_MAN
  unset GNUSTEP_USER_DOC_INFO

  unset GNUSTEP_SYSTEM_USERS_DIR
  unset GNUSTEP_LOCAL_USERS_DIR
  unset GNUSTEP_NETWORK_USERS_DIR
fi

if [ -n "$GS_ZSH_NEED_TO_RESTORE_SET" ]; then
  unsetopt shwordsplit
fi
# EOF

Re: GNU Guix 0.2 released

[Ludovic Courtès]

Germán Arias <german@xelalug.org> skribis:

> On 2013-05-17 07:27:10 -0600 ludo@gnu.org (Ludovic Courtès wrote:
> [snip]
>> 
>>> The only difference is that if the system don't know about the gnustep
>>> tools. The
>>> user will need run the gnustep script, something like ".
>>> /usr/.../GNUstep.sh", to set
>>> up the variables of gnustep environment.
>> 
>> What do you mean with “doesn’t know about the GNUstep tools”?  When is
>> it necessary to source that script?  What are the variables to be
>> defined?
>
> GNUstep can be installed using differents layouts. By default gnustep is
> installed using the FHS layout. But one popular layout is "gnustep", this
> install all in "/usr/GNUstep". Since this isn't an standard path to install
> libraries, headers and tools, the user need add this path or run the
> gnustep script at session startup or run it when he will use the
> gnustep-make tool.

OK.  As you may have seen, Guix installs each package in a directory of
its own (like GNU Stow, if that’s more familiar).  This is why Guix
already has the necessary infrastructure to set search path environment
variables like CPATH and LIBRARY_PATH (GCC’s search paths for headers
and libraries).

I guess GNUstep packages wouldn’t mind being installed each in their own
directory, provided the relevant search path environment variables are
set, right?

>> Guix has a mechanism to automatically define search path variables:
>> 
>>   http://lists.gnu.org/archive/html/bug-guix/2013-03/msg00158.html
>> 
>> Would that be of any help?
>
> I think it can help. Although I'm not an expert in what does exactly
> the gnustep script. I send you it attached if you want take a look.
> Anyway, installing gnustep with FHS layout, avoids the use of
> this script.

Well, it’s a lengthy script, but it seems that one of the important
variables is GNUSTEP_SYSTEM_ROOT, and perhaps
GNUSTEP_{LIBRARIES_,TOOLS_,}PATHLIST.

I guess we’ll need your GNUstep expertise to sort this out.  :-)

Ludo’.

Re: GNU Guix 0.2 released

[Germán Arias]

On 2013-05-18 14:54:56 -0600 ludo@gnu.org (Ludovic Courtès wrote:

[snip]
> 
> I guess GNUstep packages wouldn’t mind being installed each in their own
> directory, provided the relevant search path environment variables are
> set, right?
>

Right.
 
[snip]
> 
> Well, it’s a lengthy script, but it seems that one of the important
> variables is GNUSTEP_SYSTEM_ROOT, and perhaps
> GNUSTEP_{LIBRARIES_,TOOLS_,}PATHLIST.
> 
> I guess we’ll need your GNUstep expertise to sort this out.  :-)
> 
> Ludo’.
>

First I will familiarize myself with Guix. I'll tell you how it goes.

Regards.

Germán

Re: GNU Guix 0.2 released

[Brandon Invergo]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

Hi Germán,

> Currently I'm testing GSRC on my PC. So, my question is: What is the
> difference between Guix and GSRC? Regards.

GSRC can be thought of as a up-to-date quarterly release of all GNU
software. It automates the fetch/configure/build/install procedure and
provides the occasional patch when necessary, making it easier to
install a GNU package from source.  It has light package management
features, such as dependency resolution, but it should not be thought of
as a package manager. GSRC only provides GNU software so external
dependencies must be installed separately by the user.

Guix, on the other hand, is a full package manager that will eventually
form the foundation of a GNU distribution.  It has far more features as
a package manager, including some really novel ones that go above and
beyond the usual package management functionality (better to let Ludovic
explain).  The Guix distribution will provide all of the software
necessary to have a complete, bootable GNU system, including non-GNU
packages.  It will also handle all the fun "under-the-hood" stuff like
system configuration and initialization, etc.

Both can be used on top of an existing distro but when the Guix distro
is ready, I will subjectively say that GSRC would be more appropriate
for just installing a package or two on top of an existing system.

There is certainly some functional overlap, and this topic has come up
before as a result, but there remains a conceptual distinction.  In
fact, I've made changes to GSRC to reinforce this distinction
(i.e. removing 3rd-party dependencies).

I think that just about sums it up but I welcome other comments. :)

Cheers,

Brandon

-- 
Brandon Invergo
http://brandon.invergo.net

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: GNU Guix 0.2 released

[Ludovic Courtès]

(Stripping Cc list.)

Brandon Invergo <brandon@invergo.net> skribis:

> Guix, on the other hand, is a full package manager that will eventually
> form the foundation of a GNU distribution.  It has far more features as
> a package manager, including some really novel ones that go above and
> beyond the usual package management functionality (better to let Ludovic
> explain).

Yes.  Basically Guix is two things: a package manager (like, say,
dpkg/APT), and a distribution.

The package manager provides the features tools like APT implement.
From a user’s viewpoint, in addition to what common package managers
implement, it supports nifty features, detailed at
<http://www.gnu.org/software/guix/manual/guix.html#Features>.

From a developer’s viewpoint, its functional approach simplifies
reasoning about package composition, and allows developers to actually
check that packages do build and work together (see
<http://www.gnu.org/software/guix/manual/guix.html#Introduction>.)
Also, it has a Scheme API that makes packaging relatively easy (see
<http://www.gnu.org/software/guix/manual/guix.html#Programming-Interface>).

> The Guix distribution will provide all of the software necessary to
> have a complete, bootable GNU system, including non-GNU packages.  It
> will also handle all the fun "under-the-hood" stuff like system
> configuration and initialization, etc.

Yes.  Currently the distro has ~400 packages, and can only be used atop
a running GNU/Linux system.  In that sense, it’s comparable to GSRC in
that it provides a way to install the latest versions of GNU packages
(though GSRC has more GNU packages, I think.)

But as Brandon notes, the longer-term goal is to build “the GNU System”.
Until now, the GNU Project has been providing many independent packages,
which have been integrated and delivered to final users by others.

In a way, this is great, because it’s a sign that the free software
ideals have expanded way beyond the GNU Project.

However, I believe it’s also detrimental to GNU in several ways.
Distros have been making compromises, in particular to software freedom,
that contradict GNU’s vision.  Integration of GNU software, and cohesion
among the various GNU packages has arguably suffered.  Distros have
contributed to a disconnection between users and developers of GNU
packages.  Distro branding has made GNU, and to some extent its
political message, much less visible to users.  Etc.

Having a GNU distro is an opportunity to fix these problems.  A stronger
GNU Project is good for individual GNU packages, and it’s good for
software freedom.

Let’s build that GNU System!  :-)

Ludo’.

Re: GNU Guix 0.2 released

[Matthew Lien]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=GB2312, Size: 3468 bytes --]

2 minor (webpage) bug report:

1. the link available as pre-built
binaries<http://hydra.gnu.org/jobset/gnu/master#tabs-status>in
'Status' on
http://www.gnu.org/software/guix/ is dead.
(hydra.gnu.org down?)

2. 'Download Area' on http://savannah.gnu.org/projects/guix/ points to a
404 location.
Maybe list those two links on the project page?
    ftp://alpha.gnu.org/gnu/guix/guix-0.2.tar.gz
    ftp://alpha.gnu.org/gnu/guix/guix-0.2.tar.gz.sig


Best wishes,
BlueT - Matthew Lien - ¾š†´Ã÷



2013/5/16 Ludovic Court¨¨s <ludo@gnu.org>

> (Stripping Cc list.)
>
> Brandon Invergo <brandon@invergo.net> skribis:
>
> > Guix, on the other hand, is a full package manager that will eventually
> > form the foundation of a GNU distribution.  It has far more features as
> > a package manager, including some really novel ones that go above and
> > beyond the usual package management functionality (better to let Ludovic
> > explain).
>
> Yes.  Basically Guix is two things: a package manager (like, say,
> dpkg/APT), and a distribution.
>
> The package manager provides the features tools like APT implement.
> From a user¡¯s viewpoint, in addition to what common package managers
> implement, it supports nifty features, detailed at
> <http://www.gnu.org/software/guix/manual/guix.html#Features>.
>
> From a developer¡¯s viewpoint, its functional approach simplifies
> reasoning about package composition, and allows developers to actually
> check that packages do build and work together (see
> <http://www.gnu.org/software/guix/manual/guix.html#Introduction>.)
> Also, it has a Scheme API that makes packaging relatively easy (see
> <http://www.gnu.org/software/guix/manual/guix.html#Programming-Interface
> >).
>
> > The Guix distribution will provide all of the software necessary to
> > have a complete, bootable GNU system, including non-GNU packages.  It
> > will also handle all the fun "under-the-hood" stuff like system
> > configuration and initialization, etc.
>
> Yes.  Currently the distro has ~400 packages, and can only be used atop
> a running GNU/Linux system.  In that sense, it¡¯s comparable to GSRC in
> that it provides a way to install the latest versions of GNU packages
> (though GSRC has more GNU packages, I think.)
>
> But as Brandon notes, the longer-term goal is to build ¡°the GNU System¡±.
> Until now, the GNU Project has been providing many independent packages,
> which have been integrated and delivered to final users by others.
>
> In a way, this is great, because it¡¯s a sign that the free software
> ideals have expanded way beyond the GNU Project.
>
> However, I believe it¡¯s also detrimental to GNU in several ways.
> Distros have been making compromises, in particular to software freedom,
> that contradict GNU¡¯s vision.  Integration of GNU software, and cohesion
> among the various GNU packages has arguably suffered.  Distros have
> contributed to a disconnection between users and developers of GNU
> packages.  Distro branding has made GNU, and to some extent its
> political message, much less visible to users.  Etc.
>
> Having a GNU distro is an opportunity to fix these problems.  A stronger
> GNU Project is good for individual GNU packages, and it¡¯s good for
> software freedom.
>
> Let¡¯s build that GNU System!  :-)
>
> Ludo¡¯.
>
>


-- 
/ GPG 5296C7A8 /
/ matthew = BlueT /
/ matthew@BlueT.org /
/ Just be Perl Hacking! /

[-- Attachment #2: Type: text/html, Size: 4905 bytes --]

Re: GNU Guix 0.2 released

[Ludovic Courtès]

Hi,

Matthew Lien <bluet@bluet.org> skribis:

> 2 minor (webpage) bug report:
>
> 1. the link available as pre-built
> binaries<http://hydra.gnu.org/jobset/gnu/master#tabs-status>in
> 'Status' on
> http://www.gnu.org/software/guix/ is dead.
> (hydra.gnu.org down?)

Yeah, the web server at hydra.gnu.org is intermittently down these
days (we’re working on it.)

> 2. 'Download Area' on http://savannah.gnu.org/projects/guix/ points to a
> 404 location.
> Maybe list those two links on the project page?
>     ftp://alpha.gnu.org/gnu/guix/guix-0.2.tar.gz
>     ftp://alpha.gnu.org/gnu/guix/guix-0.2.tar.gz.sig

Indeed.  I’ve added a link from https://savannah.gnu.org/projects/guix/
to work around this problem.

Thanks for the report,
Ludo’.

Re: GNU Guix 0.2 released

[Germán Arias]

On 2013-05-15 02:53:05 -0600 Brandon Invergo <brandon@invergo.net> wrote:

> Hi Germán,
> 
>> Currently I'm testing GSRC on my PC. So, my question is: What is the
>> difference between Guix and GSRC? Regards.
> 
> GSRC can be thought of as a up-to-date quarterly release of all GNU
> software. It automates the fetch/configure/build/install procedure and
> provides the occasional patch when necessary, making it easier to
> install a GNU package from source.  It has light package management
> features, such as dependency resolution, but it should not be thought of
> as a package manager. GSRC only provides GNU software so external
> dependencies must be installed separately by the user.
> 
> Guix, on the other hand, is a full package manager that will eventually
> form the foundation of a GNU distribution.  It has far more features as
> a package manager, including some really novel ones that go above and
> beyond the usual package management functionality (better to let Ludovic
> explain).  The Guix distribution will provide all of the software
> necessary to have a complete, bootable GNU system, including non-GNU
> packages.  It will also handle all the fun "under-the-hood" stuff like
> system configuration and initialization, etc.
> 
> Both can be used on top of an existing distro but when the Guix distro
> is ready, I will subjectively say that GSRC would be more appropriate
> for just installing a package or two on top of an existing system.
> 
> There is certainly some functional overlap, and this topic has come up
> before as a result, but there remains a conceptual distinction.  In
> fact, I've made changes to GSRC to reinforce this distinction
> (i.e. removing 3rd-party dependencies).
> 
> I think that just about sums it up but I welcome other comments. :)
> 
> Cheers,
> 
> Brandon
> 

Well I think that a system to easy install will be appreciated by the final
users. Especially if it helps with find/install the requirements. There are packages
like gnustep-gui or octave that can be succesfully installed with a lot of
missed functionalities if the user don't care about the recomended requirements.
And not all people out there that want use a gnu package are programmers. So
I think GSRC can help people in this way.

Regards.
Germán.