all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: adfeno--- via <help-guix@gnu.org>
To: 44178@debbugs.gnu.org
Cc: guix-devel@gnu.org, "help-guix@gnu.org" <help-guix@gnu.org>
Subject: Re: packaging a golang package
Date: Thu, 28 Jan 2021 07:32:18 -0300	[thread overview]
Message-ID: <bf7bc90e-17b0-7393-ce02-b38a12d0ab48@hyperbola.info> (raw)
In-Reply-To: <87wnvymoxe.fsf@gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3708 bytes --]

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


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

[2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45450#5 .


-- 
* Ativista do software livre
	* https://libreplanet.org/wiki/User:Adfeno
	* 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  parent reply	other threads:[~2021-01-28 10:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08  7:01 packaging a golang package Timmy Douglas
2021-01-08 18:33 ` raingloom
2021-01-08 19:01 ` Leo Famulari
2021-01-10  0:32   ` Timmy Douglas
2021-01-11  6:09     ` Timmy Douglas
2021-01-17 13:31       ` Helio Machado
2021-01-25  7:18         ` Timmy Douglas
2021-01-25 20:49         ` Francois.JOULAUD--- via
2021-01-25 23:38           ` Helio Machado
2021-01-27 14:31           ` Katherine Cox-Buday
2021-01-28  8:18             ` Timmy Douglas
2021-01-28 10:32             ` adfeno--- via [this message]
2021-01-28 16:03               ` Ludovic Courtès
2021-01-28 21:10                 ` adfeno--- via
2021-01-29 20:57                   ` Elais Player
  -- strict thread matches above, loose matches on Subject: below --
2021-01-20  3:27 jgart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bf7bc90e-17b0-7393-ce02-b38a12d0ab48@hyperbola.info \
    --to=help-guix@gnu.org \
    --cc=44178@debbugs.gnu.org \
    --cc=adfeno@hyperbola.info \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.