[Top][All Lists]

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

Re: packaging a golang package

From: Adonay Felipe Nogueira
Subject: Re: packaging a golang package
Date: Thu, 28 Jan 2021 07:32:18 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Icedove/68.10.0

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.

Besides, since GNU Guix is committed to GNU FSDG, the package maintainers (or 
reviewers at least) would *theoretically* be obligated to observe the GNU FSDG 
requirements, otherwise the package is considered buggy, and one of those 
requirements is to guarantee that all functional/practical data/work are 
free/libre and that non-functional/non-practical data/works grant at least 
freedom 2 in full (to share and sell unlimited number of copies of the original 
to anyone for any purpose), all this would require at least a pass/check on the 
source files, the same check that is normally used in the processes of 
unbundling/unvendoring. So we might as well cut the path short.

> I dislike it, but I also don't think we should try to solve the broader
> class of issues while trying to implement an importer. It should be a
> larger discussion within the Guix community across _all_ language
> packages about how we might achieve upstream parity while still
> maintaining our goals as a distribution, all while not crippling our
> infrastructure and people :)

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

If Guix could make at least the suggestion (a) from Guix bug #45450 ([2]) work, 
I would be amazed, since it would remove the repositories from the individual 
Guix recipes that provide the single-language package managers.

Despite not being a developer focused on the plethora of single-language 
package managers out there, and not even being a developer per see, I'm also in 
favor of coordinating an effort between Guix and other package managers, but I 
think expressed/explicit commitment to the GNU FSDG by those single-language 
package managers is a sine qua non for all free/libre system distributions, 
including GuixSD, which GNU Guix also maintains.

# References


[2]: .

* Ativista do software livre
        * Membro dos grupos avaliadores de
                * Software (Free Software Directory)
                * Distribuições de sistemas (FreedSoftware)
                * Sites (Free JavaScript Action Team)
        * Não sou advogado e não fomento os não livres
* Sempre veja o spam/lixo eletrônico do teu e-mail
        * Ou coloque todos os recebidos na caixa de entrada
* Sempre assino e-mails com OpenPGP
        * Chave pública: vide endereço anterior
        * Qualquer outro pode ser fraude
        * Se não tens OpenPGP, ignore o anexo "signature.asc"
* Ao enviar anexos
        * Docs., planilhas e apresentações: use OpenDocument
        * Outros tipos: vide endereço anterior
* Use protocolos de comunicação federadas
        * Vide endereço anterior
* Mensagens secretas somente via
        * XMPP com OMEMO
        * E-mail criptografado e assinado com OpenPGP

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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