[Top][All Lists]

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

Re: packaging a golang package

From: Ludovic Courtès
Subject: Re: packaging a golang package
Date: Thu, 28 Jan 2021 17:03:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)


adfeno--- via <> skribis:

> If by vendoring we mean bundling and also make users fetch data from places 
> not explicitly committed to the GNU FSDG, then allow me to jump in to add 
> some important notes.
> Em 27/01/2021 11:31, Katherine Cox-Buday escreveu:
>> As a packager for a distribution, I dislike vendoring because of the
>> reasons you outlined above, _but_ I also dislike building upstream
>> software with versions of dependencies that weren't approved, tested,
>> and verified, upstream. It seems to me like that's a recipe for
>> unstable, maybe even insecure, software.
> I also agree that this would be problematic, but I fear that if we surrender 
> to vendoring, we might defeat the purpose of GNU Guix.

I sympathize with that feeling.

It’s definitely a hard problem.  Even Debian, which has been a
lighthouse for many on these matters, recently gave up:

I think both Katherine’s concerns and yours are valid.

IMO, the importer should be able to import things recursively and assume
we’re not going to bundle anything.  It’d be up to the packager, then,
to opt out and selectively use bundled copies of dependencies, if and
when that appears necessary.

> I'm OK with the importer approach but, *in my opinion*, I don't think this 
> tackles the true issue described on the 4th paragraph of the “License Rules” 
> described on the GNU FSDG ([1]), this is why I opened Guix bug #45450 ([2]).

IMO, ‘guix import’ does not “steer users towards obtaining any nonfree
information” any more than wget does.  It’s a tool for packagers that
returns a package definition or template thereof, and it’s up to the
packager to decide what to do with it.


reply via email to

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