Hi! On Mon, 2025-08-04 at 14:40:07 +0100, Julian Gilbey wrote: > On Sat, Jan 04, 2025 at 05:20:13PM +0800, Maytham Alsudany wrote: > > Most of the problems with wording have been fixed, except for the one I > > note below. > > [...] > > There seems to be an issue with this patch, and potentially with the > whole Static-Built-Using field syntax/semantics:
[…] > Note that these fields refer to version 0.3.2-1+b1, which is a binNMU > version, not a source package version (though it may be the source > package name). So this would presumably not be acceptable. But as > the primary purpose of the Static-Built-Using field is to record the > versions of packages used during the build, surely we should be using > *binary* packages and versions in this field, not the *source* > packages and versions? To give some context, the new field came about when concerns were raised about reuse of Built-Using for the non-license cases. So the field naturally inherited the previous semantics, just in a different field. (But I'm not saying this to argue that this is thus correct. :) > Here's where this would be relevant: > > Binary packages pkg1, pkg2, pkg3 are built from pkg1-source, > pkg2-source, pkg3-source respectively. > > pkg1 statically depends on pkg2 > pkg2 statically depends on pkg3 > > pkg1 is at version 0.1.0-1, Static-Built-Using: pkg2-source (= 0.2.0-1) > pkg2 is at version 0.2.0-1, Static-Built-Using: pkg3-source (= 0.3.0-1) > pkg3 is at version 0.3.0-1 > > pkg3-source is then updated to version 0.3.1-1 > > This requires pkg2 to be rebuilt against the new version, and a binNMU > is adequate for this purpose, so we get pkg2 version 0.2.0-1+b1, but > we still have pkg2-source version 0.2.0-1. > > But now a rebuild of pkg1 is not triggered, even though that may well > be required: pkg2-source is still at version 0.2.0-1, which pkg1 was > built against, but pkg2 has been updated. (And in the case of libjs-* > packages, I believe that this rebuild is potentially needed: pkg1 may > well incorporate bundled code from pkg2, which in turn incorporates > code from pkg3.) > > The only way to get round this in the current setup would be to do a > source upload of pkg2-source with a new version number 0.2.0-2, and > that somewhat defeats the idea of being able to do updates in an > easily automated fashion. As has been mentioned elsethread I think currently the main users of the field involve source based binary packages (similar in nature to C/C++ header-only -dev packages), where I don't think this would make much of a practical difference (because pkg1 would list both pkg2-source and pkg3-source in its Static-Built-Using). For the static library cases (libfoo.a), I'm not sure this might make (in general) much of a difference either. As I'd expect static library packages to only include objects generated from the same source package (and not from all transitive dependencies), and where the final executable or shared library (if everything else has been built with PIC/PIE), then embeds all the static libraries (and where the package should also list the equivalent of all source packages that provide libraries from say «pkgconf --static --libs libfoo»). _But_, in contrast to the license-relevant Built-Using field, where the important part is the source package (to be kept around for compliance reasons), if we do really have packages that are to be embedded by others and that are currently embedding (or might do so in the future), other transitive static content, then this would be a problem, indeed. And where using binary names and versions would be better, while this would not really affect/disrupt every other case listed above. I'm also thinking that while in general the most important part is going to be explicit source changes (in a new package revision), that cascade into whoever ends up embedding that code, there can also be generated source changes (via tools that generate source from source, f.ex. yacc), or binary object changes (via tools that generate objects from source, f.ex. gcc). Where the former would be closer to the scenario that Julian was presenting, where a package that ends up with compiled output from yacc in its libfoo.a could declare itself «Static-Build-Using: yacc (= ...)», but then it would not make much sense to transitively add that into all users of libfoo.a. But for the latter I don't think this is a problem, because this would arguably affect all/most/many binary packages in the archive, including those not statically linking/embedding, so we'd need some other way to track what to rebuild anyway (?). > I would therefore propose changing the Static-Built-Using field to use > *binary* packages and versions rather than *source* packages and > versions to fix this. > > At present, there are only about 250 packages in testing that use the > Static-Built-Using field, so the impact would be manageable. > > > But there may be a really good reason to use source package versions > instead; it would be helpful to hear those. Although we have some tooling generating the fields (mainly in the Go and Rust teams), I don't think there's currently tooling in Debian consuming the fields yet. But then also, the fields have been documented with those semantics since dpkg 1.21.3 (as present in Debian bookworm), so there could be local reliance on those. :/ If there is consensus that we'd want the more precise (although in many cases possibly irrelevant) information tracking, I'd be fine with the changed semantics, and I'd be happy to update the deb-control(5) man pages. Taking into account that while it feels early enough in Debian terms (given that we currently have no consumers that I'm aware of), this has the unknown of potential local users. Thanks, Guillem
