Scope of support for Guix on other distros

Scope of support for Guix on other distros

[David Seaward]

Hi all,

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.

The reason I ask is that cross-distro installers are increasingly
popular (for example, Flatpak and Snappy) but none of them (currently)
provide a central repository that is guaranteed free. [1][2] It
occurred to me that Guix could function as an "app store" (repository)
as well as a distro.

As well as supporting the Guix package manager on other distros, I'd
guess this would also require integration with PackageKit / GNOME
Software. [3]

Or is this kind of thinking out-of-scope for the Guix/Guix SD project
as it stands today?

Regards,
David

[1]: https://github.com/flathub/flathub/issues/116
[2]: https://bugs.launchpad.net/snapstore/+bug/1720752
[3]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=17152

Re: Scope of support for Guix on other distros

[Konrad Hinsen]

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.

Re: Scope of support for Guix on other distros

[Ludovic Courtès]

Hello,

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

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

The link:
<https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html>.

And I should add that we are committed to supporting Guix usage on other
distros.  This is an important use case.

Ludo’.

Re: Scope of support for Guix on other distros

[Christopher Allan Webber]

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.

Re: Scope of support for Guix on other distros

[ng0]

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

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:

Archlinux: https://aur.archlinux.org/packages/guix/
Gentoo: https://packages.gentoo.org/packages/sys-apps/guix
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

We could mention those on the Download page?
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://krosos.org/dist/keys/
https://www.infotropique.org https://krosos.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Scope of support for Guix on other distros

[Christopher Allan Webber]

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.

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

Re: Scope of support for Guix on other distros

[ng0]

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

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Scope of support for Guix on other distros

[Tobias Platen]

On 02.10.2017 20:52, Christopher Allan Webber wrote:
> 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.
> 
>> 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
Parabola also has guix, but an outdated version [1]. I installed the
latest binary version on my Parabola system, which I downloaded from
gnu.org.
> 
> 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? 
> 
Debian also includes GNUstep which lives in /usr/gnustep. Maybe /gnu
could be moves to /usr/gnu on Debian.

[1] https://www.parabola.nu/packages/?q=guix

Re: Scope of support for Guix on other distros

[Mark H Weaver]

Tobias Platen <trisquel@platen-software.de> writes:

> On 02.10.2017 20:52, Christopher Allan Webber wrote:
>> 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? 
>> 
> Debian also includes GNUstep which lives in /usr/gnustep. Maybe /gnu
> could be moves to /usr/gnu on Debian.

All of our binary substitutes are built with a store prefix of /gnu.
Using a different store prefix requires bootstrapping the entire system
from source code, once per core-updates cycle, and also doing frequent
rebuilds of upper layers of the stack to keep up with the updates on our
master branch.  Most users won't want to do this.

      Mark

Re: Scope of support for Guix on other distros

[Christopher Allan Webber]

Mark H Weaver writes:

> Tobias Platen <trisquel@platen-software.de> writes:
>
>> On 02.10.2017 20:52, Christopher Allan Webber wrote:
>>> 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? 
>>> 
>> Debian also includes GNUstep which lives in /usr/gnustep. Maybe /gnu
>> could be moves to /usr/gnu on Debian.
>
> All of our binary substitutes are built with a store prefix of /gnu.
> Using a different store prefix requires bootstrapping the entire system
> from source code, once per core-updates cycle, and also doing frequent
> rebuilds of upper layers of the stack to keep up with the updates on our
> master branch.  Most users won't want to do this.

I still think a hilarious option would be to "graft" every output to
/usr/gnu or /opt/gnu but I think nobody else is on board with this ;)

Re: Scope of support for Guix on other distros

[Mark H Weaver]

Hi Chris,

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> Mark H Weaver writes:
>
>> Tobias Platen <trisquel@platen-software.de> writes:
>>
>>> On 02.10.2017 20:52, Christopher Allan Webber wrote:
>>>> 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? 
>>>> 
>>> Debian also includes GNUstep which lives in /usr/gnustep. Maybe /gnu
>>> could be moves to /usr/gnu on Debian.
>>
>> All of our binary substitutes are built with a store prefix of /gnu.
>> Using a different store prefix requires bootstrapping the entire system
>> from source code, once per core-updates cycle, and also doing frequent
>> rebuilds of upper layers of the stack to keep up with the updates on our
>> master branch.  Most users won't want to do this.
>
> I still think a hilarious option would be to "graft" every output to
> /usr/gnu or /opt/gnu but I think nobody else is on board with this ;)

I've had similar thoughts in the past, but upon further reflection, it
would raise serious technical difficulties.

So far, grafting only attempts to change individual components of file
names (i.e. between two '/'s), which is prudent because it's entirely
possible that some software stores the components separately, or uses a
different directory separator internally.  I don't know how much of a
problem this would be in practice, but stranger things have happened,
e.g. <https://bugs.gnu.org/24703>.

If we neglect that issue, the next problem is that grafting obviously
cannot change the length of file names embedded within executables and
data files of arbitrary format, so in order to add 4 characters to the
beginning of file names, we'd have to discard 4 characters from
somewhere else.

Discarding 4 characters from the hash would seem to be the obvious
choice, but that would entail making it about a million times easier to
generate a hash collision.  If someone can successfully cause a hash
collision, that could be used to breach the security of the system.
There's also the fact that quite a bit of code in Guix assumes a fixed
hash length, and it would take some effort to lift that limitation.

The safer approach would be to discard 4 characters from the
human-readable part of the file names (i.e. the package name and/or
version number), which would obviously hinder readability.

This would be a lot of fuss for very little benefit, in my opinion.  The
sole benefit would be to allow Debian users to install a (very old)
version of Guix from Debian's own repository instead of having to use
our own (up-to-date) .deb file.

As a long-time Debian user myself, I can very much sympathize with the
desire to avoid using outside repositories.  My main reason for this is
that on a Debian system, I've already put full trust in the Debian
developers and infrastructure, and I'd rather avoid trusting anyone else
if I can avoid it.  However, that reason is not applicable here, because
it's not possible to use Guix without putting tremendous trust in the
Guix developers, regardless of where the original .deb came from.

If we were to try to add a package to Debian, it might be better to add
a package that downloads, authenticates, and installs our latest binary
installer.  Most importantly, this would allow us to leverage Debian's
existing infrastructure to securely distribute a copy of our signing key
to new users, and allow slightly more convenient install without
condemning users to starting with an ancient version of Guix.

What do you think?

      Mark

Re: Scope of support for Guix on other distros

[Christopher Allan Webber]

Mark H Weaver writes:

> Hi Chris,

Hi Mark,

> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> Mark H Weaver writes:
>>
>>> Tobias Platen <trisquel@platen-software.de> writes:
>>>
>>>> On 02.10.2017 20:52, Christopher Allan Webber wrote:
>>>>> 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? 
>>>>> 
>>>> Debian also includes GNUstep which lives in /usr/gnustep. Maybe /gnu
>>>> could be moves to /usr/gnu on Debian.
>>>
>>> All of our binary substitutes are built with a store prefix of /gnu.
>>> Using a different store prefix requires bootstrapping the entire system
>>> from source code, once per core-updates cycle, and also doing frequent
>>> rebuilds of upper layers of the stack to keep up with the updates on our
>>> master branch.  Most users won't want to do this.
>>
>> I still think a hilarious option would be to "graft" every output to
>> /usr/gnu or /opt/gnu but I think nobody else is on board with this ;)
>
> I've had similar thoughts in the past, but upon further reflection, it
> would raise serious technical difficulties.
>
> So far, grafting only attempts to change individual components of file
> names (i.e. between two '/'s), which is prudent because it's entirely
> possible that some software stores the components separately, or uses a
> different directory separator internally.  I don't know how much of a
> problem this would be in practice, but stranger things have happened,
> e.g. <https://bugs.gnu.org/24703>.
>
> If we neglect that issue, the next problem is that grafting obviously
> cannot change the length of file names embedded within executables and
> data files of arbitrary format, so in order to add 4 characters to the
> beginning of file names, we'd have to discard 4 characters from
> somewhere else.
>
> Discarding 4 characters from the hash would seem to be the obvious
> choice, but that would entail making it about a million times easier to
> generate a hash collision.  If someone can successfully cause a hash
> collision, that could be used to breach the security of the system.
> There's also the fact that quite a bit of code in Guix assumes a fixed
> hash length, and it would take some effort to lift that limitation.
>
> The safer approach would be to discard 4 characters from the
> human-readable part of the file names (i.e. the package name and/or
> version number), which would obviously hinder readability.
>
> This would be a lot of fuss for very little benefit, in my opinion.  The
> sole benefit would be to allow Debian users to install a (very old)
> version of Guix from Debian's own repository instead of having to use
> our own (up-to-date) .deb file.

That's an interesting summary of things.  Okay, I'm convinced the "graft
our problem away" route won't work here.

> As a long-time Debian user myself, I can very much sympathize with the
> desire to avoid using outside repositories.  My main reason for this is
> that on a Debian system, I've already put full trust in the Debian
> developers and infrastructure, and I'd rather avoid trusting anyone else
> if I can avoid it.  However, that reason is not applicable here, because
> it's not possible to use Guix without putting tremendous trust in the
> Guix developers, regardless of where the original .deb came from.
>
> If we were to try to add a package to Debian, it might be better to add
> a package that downloads, authenticates, and installs our latest binary
> installer.  Most importantly, this would allow us to leverage Debian's
> existing infrastructure to securely distribute a copy of our signing key
> to new users, and allow slightly more convenient install without
> condemning users to starting with an ancient version of Guix.
>
> What do you think?

Hm.  I know I personally am wary of packages that are there just to be
installers for other packages (even though in effect if you do a guix
pull with a base package, you're kind of doing that anyway).  I'd
suspect we'll get more mileage at this point by just generating .deb
files and hosting them on our own site.

Thanks for the insightful comments!

Re: Scope of support for Guix on other distros

[Ricardo Wurmus]

Christopher Allan Webber <cwebber@dustycloud.org> writes:

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

I was thinking about adding support for the “deb” package format to
“guix pack”.  We can already create fat tarballs, so it shouldn’t be too
much effort to create fat Debian archives.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Scope of support for Guix on other distros

[David Seaward]

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

> And I should add that we are committed to supporting Guix usage on other distros. This is an important use case.

Many thanks regarding this and other replies. I'll send follow up
questions in new threads.

Regards,
David

Re: Scope of support for Guix on other distros

[Christopher Allan Webber]

Ricardo Wurmus writes:

> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> 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?
>
> I was thinking about adding support for the “deb” package format to
> “guix pack”.  We can already create fat tarballs, so it shouldn’t be too
> much effort to create fat Debian archives.

I think this would be a huge win!

Re: Scope of support for Guix on other distros

[Ludovic Courtès]

Christopher Allan Webber <cwebber@dustycloud.org> skribis:

> Ricardo Wurmus writes:
>
>> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>>
>>> 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?
>>
>> I was thinking about adding support for the “deb” package format to
>> “guix pack”.  We can already create fat tarballs, so it shouldn’t be too
>> much effort to create fat Debian archives.
>
> I think this would be a huge win!

Indeed!  .deb is quite simple:
<https://en.wikipedia.org/wiki/Deb_%28file_format%29>.

It wouldn’t be optimal in that the generated package would be
self-contained: it would bring its own Guile, libgc, etc. instead of
using those of the host distro.  But it does mean that it would work
pretty well.  :-)

Another option would be to make a derivation that runs Checkinstall in a
Debian VM, which would provide a package that’s better integrated with
Debian, but it’s more tedious.

Ludo’.

Re: Scope of support for Guix on other distros

[Ludovic Courtès]

Hello,

In other news, somebody is trying to get Nix into Debian:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877019

Might be worth seeing if they manage to overcome the administrative
issues, which are going to be the same as for Guix.

(Seen on <https://reproducible.alioth.debian.org/blog/drafts/127/>.)

Ludo’.

Re: Scope of support for Guix on other distros

[ng0]

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

Ricardo Wurmus transcribed 0.5K bytes:
> 
> Christopher Allan Webber <cwebber@dustycloud.org> writes:
> 
> > 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?
> 
> I was thinking about adding support for the “deb” package format to
> “guix pack”.  We can already create fat tarballs, so it shouldn’t be too
> much effort to create fat Debian archives.
> 
> -- 
> Ricardo
> 
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
> 
> 
> 

If it helps, this is how cURL/gnURL creates rpms (or at least cURL):

# Build source and binary rpms. For rpm-3.0 and above, the ~/.rpmmacros
# must contain the following line:
# %_topdir /home/loic/local/rpm
# and that /home/loic/local/rpm contains the directory SOURCES, BUILD etc.
#
# cd /home/loic/local/rpm ; mkdir -p SOURCES BUILD RPMS/i386 SPECS SRPMS
#
# If additional configure flags are needed to build the package, add the
# following in ~/.rpmmacros
# %configure CFLAGS="%{optflags}" ./configure %{_target_platform} --prefix=%{_prefix} ${AM_CONFIGFLAGS}
# and run make rpm in the following way:
# AM_CONFIGFLAGS='--with-uri=/home/users/loic/local/RedHat-6.2' make rpm
#

rpms:
        $(MAKE) RPMDIST=curl rpm
        $(MAKE) RPMDIST=curl-ssl rpm

rpm:
        RPM_TOPDIR=`rpm --showrc | $(PERL) -n -e 'print if(s/.*_topdir\s+(.*)/$$1/)'` ; \
        cp $(srcdir)/packages/Linux/RPM/$(RPMDIST).spec $$RPM_TOPDIR/SPECS ; \
        cp $(PACKAGE)-$(VERSION).tar.gz $$RPM_TOPDIR/SOURCES ; \
        rpm -ba --clean --rmsource $$RPM_TOPDIR/SPECS/$(RPMDIST).spec ; \
        mv $$RPM_TOPDIR/RPMS/i386/$(RPMDIST)-*.rpm . ; \
        mv $$RPM_TOPDIR/SRPMS/$(RPMDIST)-*.src.rpm .


-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://krosos.org/dist/keys/
https://www.infotropique.org https://krosos.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Scope of support for Guix on other distros

[Hartmut Goebel]

Am 07.10.2017 um 12:11 schrieb ng0:
> If it helps, this is how cURL/gnURL creates rpms (or at least cURL):
> […]
>         rpm -ba --clean --rmsource $$RPM_TOPDIR/SPECS/$(RPMDIST).spec ; \

I'm afraid this information does not help much, since they "simply" run
the rpm build command and process the .spec file.

Anyway you inspired me to search the definition of the RPM file format:
it can be found at <http://rpm.org/devel_doc/file_format.html>. A more
technical description is at
<http://ftp.rpm.org/max-rpm/s1-rpm-file-format-rpm-file-format.html>.
For both sources I can't tell if they are up-to-date.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Scope of support for Guix on other distros

[Adonay Felipe Nogueira]

Personally, I'm against mentioning these in the download page, the
reason being that I *think* it is somewhat like recommending non-free
system distributions.

ng0 <ng0@infotropique.org> writes:

>
> By my own observation, systems including Guix either officially
> or by third-party / community methods:
>
> Archlinux: https://aur.archlinux.org/packages/guix/
> Gentoo: https://packages.gentoo.org/packages/sys-apps/guix
> 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
>
> We could mention those on the Download page?

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: Scope of support for Guix on other distros

[Mark H Weaver]

Hi,

David Seaward <dseaward925@gmail.com> writes:

> 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.
>
> The reason I ask is that cross-distro installers are increasingly
> popular (for example, Flatpak and Snappy) but none of them (currently)
> provide a central repository that is guaranteed free.

"Guarantee" is a stronger word than could be applied to Guix.  We are
fortunate to have a large number of volunteers adding packages, but we
don't have the resources to check all of their work.

What we can say is that if software freedom issues in Guix are brought
to our attention (more precisely: non-compliance with the GNU FSDG [1]),
we will make it a high priority to fix those issues ASAP.

      Mark


[1] https://www.gnu.org/distros/free-system-distribution-guidelines.html

Re: Scope of support for Guix on other distros

[Pjotr Prins]

Hi David,

On Mon, Oct 02, 2017 at 11:18:12AM +0200, David Seaward wrote:
> Hi all,
> 
> 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.
> 
> The reason I ask is that cross-distro installers are increasingly
> popular (for example, Flatpak and Snappy) but none of them (currently)
> provide a central repository that is guaranteed free. [1][2] It
> occurred to me that Guix could function as an "app store" (repository)
> as well as a distro.

Some deja vu ;). And if they don't have the isolation that Guix has
these package managers will break. They all do.

> As well as supporting the Guix package manager on other distros, I'd
> guess this would also require integration with PackageKit / GNOME
> Software. [3]

It would only take Debian to accept Guix as a first class citizen.
Less odd then it looks, because they also allow cpan and what not.
But, so far, they have rejected inclusion of the Guix package manager.

> Or is this kind of thinking out-of-scope for the Guix/Guix SD project
> as it stands today?

Guix works perfectly as a package manager on another distro, as long
as you have root. Many people do that here. I agree that we could
present that better to the outside world. 

Pj.