[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#74917] [PATCH] gnu: Syncthing: Update to 1.28.1.
From: |
Leo Famulari |
Subject: |
[bug#74917] [PATCH] gnu: Syncthing: Update to 1.28.1. |
Date: |
Wed, 18 Dec 2024 13:41:45 -0500 |
On Mon, Dec 16, 2024 at 09:44:33PM +0000, Sharlatan Hellseher wrote:
> I've notice syncthing was build from source without vendor that swap
> back to the release tarball containing bundled vendor.
Yes, we made that change a while ago.
For me, I decided that I didn't think that "unbundling" the dependencies
was a good use of my time so I stopped doing it.
> Would it be reasonable to built it completely relaying on the packages
> available in Guix, WDYT?
Personally, I don't think it's reasonable.
The GPL says that source code must be available in "the preferred form
of the work for making modifications to it."
https://www.gnu.org/licenses/gpl-3.0.en.html
Syncthing is not GPL, but I think that requirement is a good guideline
for us to follow so that Guix can give the benefits of GNU and the GPL
to our users.
For Go software, the preffered from for editing is a Git tree with
bundled / vendored dependencies at specific Git commits. Not a bunch of
separate trees that the user would have to laboriously re-assemble.
However, if we must unbundle, we could consider creating a new Guix
mechanism to ease the maintenance burden of Go packages: package
variants with parameterized versions.
For example, you have a main package variant of some Go module, call it
go-foo. That looks like a normal Guix package. If a package needs to use
go-foo, it would look like this:
(inputs
(list (go-foo
"1.0.0"
"cabba6edr1x2231hw0zsxm53sw34wxcs4ijjjcnzcg1vz9drjrg9")))
At least that would be easy for package maintenance.
But I think that using the bundled dependencies for Go packages is the
right thing to do from a GNU perspective. Of course we have to make sure
they are all free software.