Paul Wise <p...@debian.org> writes: > Hi all, > > I noticed that sometimes Debian's choice of upstream source for > packaging can be suboptimal. This is especially apparent for the > different per-language upstream packaging ecosystems[1], where the > upstream packaging differs from the upstream VCS in some significant > ways, including missing files, prebuilt files, embedded copies etc. > > While the upstream VCS also sometimes has these issues, it is often > much less problematic than the upstream packaging ecosystems.
While I agree with the points you raise, and think I agree with your overall goal, I see some problems with using upstream VCS as a source for Debian packaging: 1) Trust paths. Some upstreams sign release tarballs with an OpenPGP release key that Debian trust for making releases. Not all upstream uses the same key to sign VCS tags/commits, and not all upstreams sign VCS tags/commits at all. While Debian can encourage and promote new policies for upstream here, I don't think we are in a position to require any uniform set of rules. Signing tarballs is the current established best practice -- moving to VCS builds needs a set of new schemes to be established and deployed, and I don't see any single universal solution today. 2) Bootstrapping projects from VCS is complex and requires additional tools, and I think the Debian packaging process is well suited for this. Two examples that I have run into: 2a) Gnulib. Several GNU-related projects import files from gnulib during VCS bootstrapping, and the way this happens is different for different projects. The correct version of the files must be imported in the right way for things to work, and knowledge of which gnulib version is used is not always present in VCS but only in a released tarball. How would this work when packaged in Debian? A debian package containing the gnulib git repository could be added, to allow source packages to checkout the right version during build. 2b) Cross-compilation and dependency cycles. Bootstrapping from VCS may require a lot of tools that are optional when building from tarball, and in my experience the complete set of tools to bootstrap a project is rarely added as Build-Dep to Debian packages. I feel some additional package build dependency mechanism would help here: maybe a Build-Bootstrap-Dep header to list the tools needed to generate a Debian source package? And Build-Dep could list the tools needed to build Debian binary packages from the Debian source package. I admit my understanding of the Debian packaging system is quite limited though. 3) Bootstrappable builds. I think the underlying goal when it comes to building from VCS may be to achieve bootstrappable builds -- see https://www.bootstrappable.org/ -- however it seems to me that a lot of care has to be taken when moving from tarball builds to VCS builds so we don't make it harder to re-bootstrap the entire toolchain. For example, building GNU Coreutils from a tarball works fine in extremely old environments, but building GNU Coreutils from VCS requires modern tools, and perhaps some of them doesn't support older environments any more. /Simon
signature.asc
Description: PGP signature
