[Top][All Lists]

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

Re: Developing free non-gnu operating systems

From: Denis 'GNUtoo' Carikli
Subject: Re: Developing free non-gnu operating systems
Date: Thu, 30 Sep 2021 16:05:07 +0200

On Wed, 29 Sep 2021 11:12:18 -0500 wrote:
> If the binary is exactly the same as another generated by another
> user, that one is used to avoid recompiling every time the same
> package.  So that is a substitute that can be audited.  That is the
> default behavior. But it can be changed.
> So all packages cannot be audited because new compiling options are
> possible every time.  Hence, it is not possible that Guix package
> manage complies with FSDG every time.
> I suggest you try this, Dennis.  Then you can see what I am talking
> about.
The packages themselves are tracked in git so they can be audited.

If you are talking about package transformations like --help-transform,
the options look self explanatory.

Some of the options like --without-tests, --with-debug-info,
--with-input, etc look safe

But some others should be the responsibility of users, like
--with-source, --with-branch, --with-latest, --with-patch,

I see no issue here as long as the separation between what the
distribution does and doesn't do is clear for all users.

For instance you can take a fully free software web browser without
JavaScript (so with no freedom issues there) and manage to download
nonfree software with that, and even follow some installation
instructions to get that nonfree software installed.

The distribution would not be responsible here. In another hand if some
packages have builtin packages manager (like web browsers which points
to addons for instance) and the consensus on that is that the
distribution is responsible for cleaning that up.

As Guix is many things at the same time I see nothing wrong with using
Guix as a tool to build software. I for instance use it to build
a library I maintain (libsamsung-ipc) in many different configurations
before pushing commits to it.

Here at least to me that separation looks clear: with --with-source,
--with-patch --with-git-url and --with-branch for instance it's probably
self-explanatory that you are on your own as you are providing the
repository URL, and so it most likely wasn't checked by Guix
contributors and users, instead you're the one that is responsible for
checking it (or not checking it).

With --with-latest, things blur a little bit but there is probably not
a lot of risk here if the package was already FSDG compliant in the
first place.

With all these option, that part of Guix looks more like a tool to
build software here, and checking if that software would be the
responsibility of the individual users. 

Parabola can also build PKGBUILDs with makepkg (and on the Internet you
can find PKGBUILDs for nonfree software). If you could build PKGBUILD
from an URL that you chose, I don't see how the distribution could be
responsible. You can also replace Parabola mirrors and repository by
Arch Linux mirrors and here I don't see either why the distribution
should be responsible of that.

When using stock packages, the responsibility of ensuring that it's
FSDG compliant lies on the project (so the collective of its users and

Where things are more problematic, is when the repositories URL are
already provided by the distribution or the package. And here there
seem to be some consensus that it's the distribution responsibility.

Examples are browsers, programming languages packages managers (like
pip), debootstrap, etc. Here as the users don't have to look for URLs
themselves and everything is already integrated in the packages, so it
should be up to the distributions to make sure that everything is ok. 

And as I understand, most FSDG distributions have these programming
language package managers. Parabola is reviewing the policy of some of
these programming language package managers in at least one of its bug

Guix has some of these programming language package managers too. The
advantage of Guix over other distributions here is that it is in better
position to fix things if something goes wrong.

With Guix import, you can get a package definition from several of
these programming language repository and the idea here is that you
would modify the resulting package definition if needed, check if it's
FSDG compliant and send a patch to Guix to add it.

So at least if something goes wrong you can resort to packaging many of
the components you need in a way that is way faster than doing it from
scratch, leaving you more time to do the checks you need to do instead.


Attachment: pgpv2Ce9PAMa1.pgp
Description: OpenPGP digital signature

reply via email to

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