Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)
On 18/01/18 21:50, Adrian Bunk wrote:
> On Thu, Jan 18, 2018 at 06:52:57PM +0100, Emilio Pozuelo Monfort wrote:
>> On 10/01/18 01:29, Sam Hartman wrote:
>>> A build profile seems like a great way to express the flag, and like
>>> many things in Debian, the work would fall on those who would benefit
>>> from it.
>>
>> I think it'd be better to be able to mark a build-dependency as optional, and
>> then implement a mechanism in dpkg to disable the undesired build-dependencies.
>> E.g. if packages start marking libselinux-dev as <optional>, with autoconf or
>> similar automatically disabling selinux support when not present, then a user
>> could build the package with something like dpkg-buildpackage
>> --disable-optional=libselinux-dev. This way we don't need a different build
>> profile for each build-dep and package, which would end up in a mess. Of course
>> we need to change the above syntax to not clash with build profiles, and add
>> DEB_BUILD_OPTIONS support, but you get the point I hope. Seems a lot more
>> standard to me than having each package define its own profiles for each
>> optional dependency.
>
> When the sole purpose of a rebuild is to get rid of unused library(ies),
> the rebuild only makes sense if this is supported throughout the whole
> distribution.
>
> The problematic cases are the non-trivial ones,
> and what support Debian wants to provide for that.
>
> It would make the life for the Devuan people much easier if Debian
> would be committed to have *all* packages in buster build and work
> with --disable-optional=libsystemd-dev.
>
> Are you as release manager willing to make this a supported feature
> for buster, with breakages being RC bugs?
>
> For small embedded systems, having this only for one library
> doesn't bring that many benefits.
>
> For how many libraries are you release manager willing to make
> --disable-optional a supported feature for buster, with breakages
> being RC bugs?
Nothing of this sort is going to be RC, no matter if we implement it via build
profiles or by some other mechanism. I'm not even sure we need it. My only point
is that if we are going to start adding this for every optional feature as it
was being suggested, we should do it properly and not abusing build profiles.
Cheers,
Emilio
Reply to: