Hi Helmut and all, Quoting Helmut Grohne (2016-07-13 06:27:49) > > 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 actually do not see the profile name as a distinguishing aspect for > whether a profile is clean anymore. While that was the intention, it > clearly does not meet established practise. Some stage and nodoc > profiles are indeed clean. > > Thus if we want to have this separation, I believe that it should be at > source package granularity and that it should be a white list (i.e. > default all profiles to dirty). lets make this instead: All profiles clean by default. Extra measures should be required if one wants to do something that has a higher possibility to break something else. > A rather odd twist of this would be separating the entire profile namespace > by prefixing clean profiles with some kind of marker. I'd see either > annoyingly long profile names or people confused about which one to use. Another approach: Add an extra field to binary package stanzas which looks like: Build-Profiles-Content-Changes: <stage1> <stage2> This field is not forwarded to binary package but instead, dpkg will know through this field, that if that binary package was built with stage1 or stage2 active, then it must add a Built-For-Profiles field to indicate with which profile the package was built. In all other cases, binary packages will not have the Built-For-Profiles because it is not necessary if their content is bit-by-bit the same. > In general, I sometimes wish there was a way for packages to explicitly > declare which profiles they support beyond scraping the various fields that > happen to contain them. Maybe a prospective amendment to the profile syntax > could try to address this as well? And let people manually maintain the field? I rather write some code for dpkg which gathers all that data at build time and then exports that summary into the source package metadata. Or maybe that's what you meant in the first place. > I see two reasons to dislike killing the field entirely: > > * .buildinfo files are not recorded in the archive (yet). > * If your installation breaks for some reason, it would be nice to be > able to tell if any installed packages were built for profiles. > > Given that the former is being solved by the reproducible folks and that > we do not record DEB_BUILD_OPTIONS either, maybe these reasons are not that > severe in the end? Maybe the better tradeoff indeed is to kill it. The latter would be my reason for demanding that binary packages stay identical by default. I'd assume that if people start with this mindset, then there will be less problems like this one. So by my proposal above, a person building a custom package for local installation would just mark it as "dirty" and would then get their Built-For-Profiles field back. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature