[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: De-vendoring gnulib in Debian packages
From: |
Simon Josefsson |
Subject: |
Re: De-vendoring gnulib in Debian packages |
Date: |
Sat, 11 May 2024 18:35:56 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Bruno Haible <bruno@clisp.org> writes:
> Simon Josefsson wrote:
>> Finally, while this is somewhat gnulib specific, I think the practice
>> goes beyond gnulib
>
> Yes, gnulib-tool for modules written in C is similar to
>
> * 'npm install' for JavaScript source code packages [1],
> * 'cargo fetch' for Rust source code packages [2],
>
> except that gnulib-tool is simpler: it fetches from a single source location
> only.
>
> How does Debian handle these kinds of source-code dependencies?
I don't know the details but I believe those commands are turned into
local requests for source code, either vendored or previously packaged
in Debian. No network access during builds. Same for Go packages,
which I have some experience with, although for Go packages they lose
the strict versioning so if Go package X declare a depedency on package
Y version Z then on Debian it may build against version Z+1 or Z+2 which
may in theory break and was not upstream's intended or supported
configuration. We have a circular dependency situation for some core Go
libraries in Debian right now due to this.
I think fundamentally the shift that causes challenges for distributions
may be dealing with packages dependencies that are version >= X to
package dependencies that are version = X. If there is a desire to
support that, some new patterns of the work flow is needed. Some
package maintainers reject this approach and refuse to co-operate with
those upstreams, but I'm not sure if this is a long-term winning
strategy: it often just lead to useful projects not being available
through distributions, and users suffers as a result.
/Simon
signature.asc
Description: PGP signature