guix-devel
[Top][All Lists]
Advanced

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

Re: Scope of support for Guix on other distros


From: ng0
Subject: Re: Scope of support for Guix on other distros
Date: Mon, 2 Oct 2017 19:12:54 +0000

Christopher Allan Webber transcribed 1.7K bytes:
> ng0 writes:
> 
> > Christopher Allan Webber transcribed 0.6K bytes:
> >> Konrad Hinsen writes:
> >> 
> >> > On 02/10/2017 11:18, David Seaward wrote:
> >> >
> >> >> To what extent is support for other distros a priority for the Guix
> >> >> project? In other words, explicitly planning to make Guix available as
> >> >> an alternate installation source on non-Guix-SD distros.
> >> >
> >> > That's already possible right now. Go to the download page and check for 
> >> > "GNU Guix 0.13.0 Binary". This is Guix for other Linux distros, as a 
> >> > look at the installation instructions will confirm. I am using this on a 
> >> > Ubuntu 16.04 LTS installation on my laptop.
> >> >
> >> > Konrad.
> >> 
> >> It would still be nice if we provided .deb/.rpm/etc files on that page.
> >
> > By my own observation, systems including Guix either officially
> > or by third-party / community methods:
> 
> Cool!
> 
> > Archlinux: https://aur.archlinux.org/packages/guix/
> > Gentoo: https://packages.gentoo.org/packages/sys-apps/guix
> 
> These provide Guix in their own upstream repository so I think it would
> be good to mention on the Download page.

See below for related comment coupled.

> > Debian: from past discussion and on request from Whonix iirc it is currently
> >         not possible due to Debian Packaging Standards (expected package
> >         behavior) or something along the lines, see guix-devel archives.
> > Fedora: https://copr.fedorainfracloud.org/coprs/lantw44/guix/
> > Slackware: https://slackbuilds.org/repository/14.2/system/guix/
> >            is on 0.12, needs an update. Any slacker up for that task?
> >            Otherwise, ping the maintainer:
> >            > Maintained by: Hunter Sezen
> 
> Since these don't provide Guix in the main repo (and Debian won't
> because we violate the FHS with /gnu/) we could probably auto-generate
> the .deb or .rpm from some gexp?

As far as I know AUR (= Arch User Repositories) has similarities to
some degree with Slackbuilds.org. I'm not 100% sure about Slackbuilds.org,
but AUR is accepted within the community but a "no warranty, no support"
kind of thing.

Moving on,
Your idea is good, but only as long as we don't have to put too much
work into it (I had a slightly heated discussion with the PyBitmessage
maintainer about trying to support too many system packages within
the source and its build system.
As long as there's someone within the community taking on this task
it should be maintained by them. Of course if we can generate those
files in a reliable way it removes the requirement for them to maintain
files outside of Guix.
These generated files could be provided in our ftp.gnu.org directory
for every release, so that our make dist also runs the "make rpm" and
"make deb", if we decide to do this.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://krosos.org/dist/keys/
https://www.infotropique.org https://krosos.org

Attachment: signature.asc
Description: PGP signature


reply via email to

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