Hi, I'm removing #757760 from the recipients because that bug should contain a discussion about the implementation of the current build profile spec and should not be a discussion platform for further additions or changes to the spec. Lets use debian-dpkg@ to discuss this issue. Quoting Javier Serrano Polo (2016-07-10 19:25:59) > On Sat, 09 Jul 2016 23:56:03 +0200 Johannes Schauer <josch@debian.org> > wrote: > > I'm CC-ing debian-dpkg@. > > I cannot CC lists.debian.org. You will not see my messages in > https://lists.debian.org/debian-policy/2016/07/threads.html . you could subscribe to whitelist@lists.debian.org. That way you can post to all Debian mailing lists without having to subscribe to them. > > I suspect you want to express "this package has to be built when no > > profiles are active as well as when the pkg.linux.zlib profile is > > active"? > > Yes. > > > If so, then why do you need the Build-Profiles field at all? > > Because the package should not be built if other pkg.linux.* profiles > are active. So, what you are suggesting is a short-hand for something where currently you'd have to write: Build-Profiles: <!pkg.linux.foo !pkg.linux.bar !pkg.linux.baz ...> How long will these lists become? Are there many examples of packages where doing something like this would be desirable? > > What is your use case? > > There is an introduction at https://bugs.debian.org/830524 . The goal is > to build a subset of binary packages. For instance, the linux source > package should have a way to build only linux-image-4.6.0-1-686 (profile > pkg.linux.686), only linux-image-4.6.0-1-rt-686-pae (profile > pkg.linux.rt-686-pae), etc. The nodebug profile would be useful to not > build *-dbg packages. What you described in that bug seems to be different from your examples. In your original bug #830524 you propose flavours for packages to build them with different libc or certain extensions disabled or enabled (Gentoo USE flag style). Indeed, build profiles are able to give you all that but why is this useful for src:linux? It seems that you want to build *single* binary packages only? Why? Is there a reduction in compilation time that you want for debugging and testing purposes? > > > I gather that the Built-For-Profiles field is written to DEBIAN/control > > > Why do you want to avoid this field? Why would this be useful? > > Binary packages should be exactly the same as if built without active > profiles. This helps making and checking a subset of reproducible > packages. This problem is already known: https://wiki.debian.org/BuildProfileSpec#Interaction_with_ReproducibleBuilds Most build profiles are supposed to create identical binary packages no matter whether the build profile is active or not. This requirement though is made impossible by the Built-For-Profiles field which will make the binary packages unique depending on the active build profiles. Having the binary packages actually be bit-by-bit identical for all build profiles that are not supposed to change binary package content would be desirable because it would - allow to check if the policy to not alter the binary package content was actually met - extend the benefits of the reproducible builds effort to profile built binary packages One way to solve this, would be to change the build profile spec to say that the Built-For-Profiles field is only to be added if either one of the following build profiles was active during the build: - pkg.$sourcepackage.$anything - stage1 - stage2 - nodoc Though I'm not sure whether keeping this static list in dpkg would be very smart. One way to avoid having to keep a list of "dirty" build profiles in dpkg would be to extend the requirement of producing identical binary packages to all profile names. I can see how this would make using above four profiles more inconvenient. I just still see the temptation of abusing above profile names in ways that breaks dependency resolvers. I'm also wondering why keeping the content of the field directly in the binary package is necessary in the first place. Is it to be able to debug problems with the binary package later on? We are already throwing away other useful information about how the binary package was built like: - which packages and versions were installed during the build - the build path or - the time of the build In fact, all of the above items are part of the .buildinfo file. Binary package time stamps were one of the last things that got removed from the binary package meta data. Maybe we should use the same logic and reasoning behind that change for the content of the Built-For-Profiles field as well and just move it into the .buildinfo file? What do you think? Thanks! cheers, josch
Attachment:
signature.asc
Description: signature