Hi,
On 12/17/25 8:36 PM, W. Michael Petullo via golang wrote:
As per Changes/GolangPackagesVendoredByDefault [1], all golang libraries
that are currently leaves (as defined in [2]) will be mass retired. This
will happen in the coming days. The full list of packages is available at
[3].
I am glad to see this. The vendored-dependency approach has made my
maintenance of Fedora's Hugo package much easier. Gone is the dread
that each version of Hugo will require multiple package reviews of new
Go dependencies. Thank you!
Glad to hear!
Yet I do worry about some packages. The golang-modernc series, for
example, has a number of idiosyncrasies that I would not want each
application packager to have to relearn.
At least for the modernc sqlite3 package, it's possible to patch it out
in favor of https://github.com/mattn/go-sqlite3/ which is also able to
be linked against the system libsqlite3 [1], unlike the modernc version.
You can see the trivy package for an example of this. I think syncthing
allows using go buildtags to choose between a modernc sqlite3 and mattn
sqlite3 backend, so for that package, not much extra work is required at
all.
But if you could elucidate what those issues are so we can potentially
come up with a solution, that would be helpful.
Is there a way to establish exceptions to the leaf-implies-retirement
rule?
I can exclude those packages when I perform the retirements if you'd like.
Is there a way for an otherwise vendored-dependency application to make use of
external Go packages when there are exceptional circumstances?
Again, It would be helpful to know what those exceptional circumstances
are, but it is probably possible (with some fiddling) to use Go
workspaces like Debian does [2] to use certain dependencies from the
/usr/share/gocode tree and then source the rest from the vendor directory.
There was discussion in the Packaging Committee ticket about making the
Guidelines laxer and saying that new packages SHOULD be built with
vendoring and Go Vendor Tools to still allow using the old approach. But
I'm not super convinced. The golang-*-devel packages and the associated
automation are not being maintained, the old tooling is not compliant
with the new licensing guidelines, and the unbundling approach has
clearly proved unsustainable. Therefore, I don't think a hybrid approach
or allowing more packages using the old approach to be introduced into
the distribution is going to work out well in the long term. It
undermines the overarching goal of this change — i.e., to simply and
unify Go packaging in the entire distribution and not rely on
unmaintained and out-of-date components.
Best,
Maxwell
[1] https://github.com/mattn/go-sqlite3/
[2] https://gitlab.com/fedora/sigs/go/go-rpm-macros/-/issues/31
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
