Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.devel > #111730
| From | Simon Josefsson <simon@josefsson.org> |
|---|---|
| Newsgroups | linux.debian.devel |
| Subject | Re: De-vendoring gnulib in Debian packages |
| Date | 2024-05-11 18:40 +0200 |
| Message-ID | <ICXVn-cE4J-3@gated-at.bofh.it> (permalink) |
| References | <ICVAd-cCO8-5@gated-at.bofh.it> <ICXiG-cDCa-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
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
Back to linux.debian.devel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
De-vendoring gnulib in Debian packages Simon Josefsson <simon@josefsson.org> - 2024-05-11 16:10 +0200
Re: De-vendoring gnulib in Debian packages Bruno Haible <bruno@clisp.org> - 2024-05-11 18:00 +0200
Re: De-vendoring gnulib in Debian packages Simon Josefsson <simon@josefsson.org> - 2024-05-11 18:40 +0200
Re: De-vendoring gnulib in Debian packages Paul Eggert <eggert@cs.ucla.edu> - 2024-05-11 18:50 +0200
Re: De-vendoring gnulib in Debian packages "Theodore Ts'o" <tytso@mit.edu> - 2024-05-12 14:10 +0200
Re: De-vendoring gnulib in Debian packages Simon Josefsson <simon@josefsson.org> - 2024-05-12 16:30 +0200
Re: De-vendoring gnulib in Debian packages "Theodore Ts'o" <tytso@mit.edu> - 2024-05-12 21:00 +0200
gzip --rsyncable (was: Re: De-vendoring gnulib in Debian packages) Simon Josefsson <simon@josefsson.org> - 2024-05-20 10:30 +0200
Re: De-vendoring gnulib in Debian packages Russ Allbery <rra@debian.org> - 2024-05-12 17:50 +0200
Re: De-vendoring gnulib in Debian packages Ansgar 🙀 <ansgar@43-1.org> - 2024-05-12 18:30 +0200
Re: De-vendoring gnulib in Debian packages Russ Allbery <rra@debian.org> - 2024-05-12 19:50 +0200
csiph-web