[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: wild speculations about build profile specification changes

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

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.


cheers, josch

Attachment: signature.asc
Description: signature

Reply to: