Re: Using build profiles beyond bootstrapping&cross (was: Re: Can/should we have an efi/efi-any platform architecture?)
Hello,
On 12 December 2014 at 11:48, Johannes Schauer <j.schauer@email.de> wrote:
> Hi,
>
> Quoting Simon McVittie (2014-12-12 12:09:05)
>> Yes, but I think that's exactly what I want for dbus' use-case? I want
>> to build-depend on valgrind (I thought it was valgrind-dev, but it's
>> actually valgrind) on exactly those architectures to which valgrind has
>> been ported, so that the debug "flavour" of libdbus can have its
>> optional valgrind instrumentation on those architectures; but on
>> architectures to which valgrind has not yet been ported, dbus still
>> needs to produce working binaries.
>>
>> Some packages solve this by copying (a random snapshot of) the valgrind
>> headers into their source code, but I'd prefer to minimize the number of
>> embedded code copies.
>>
>> At the moment that's:
>>
>> Build-Depends: ..., valgrind [amd64 armhf i386 mips mipsel powerpc ppc64
>> s390x], ...
>>
>> which is an inconvenient amount of hard-coding, and has led to one RC
>> bug already (when valgrind dropped support for armel). With build
>> profiles (which I'll reinstate in unstable when jessie becomes stable)
>> it would be something like:
>>
>> Build-Depends: ..., valgrind [amd64 armhf i386 mips mipsel powerpc ppc64
>> s390x] <!stage1>, ...
>>
>> but I'd rather have
>>
>> Build-Depends: ..., valgrind <arch-where-valgrind-exists> <!stage1>, ...
>>
>> or whatever spelling.
>
> okay. I get you now.
>
> Debian build profiles can express what USE flags do for Gentoo. What you
> probably want is:
>
> Build-Depends: ..., valgrind <!without-valgrind>, ...
>
<snip>
unlike Simon, I would tend to agree that we do want this. It's indeed
not quite USE flags, but rather encoding per-arch default build
dependencies. E.g. the way we encode default MPI per-arch
implementation, default Java per-arch implementation and etc. However,
this would imply to maintain default set of per-arch profiles
somewhere, update them, and always use them.
And secondly, I like that build-profiles can be used in a standard
fashion to support non-free configurations of rebuilding main
packages, aka <with-openssl>. But this use case is supportable with
existing profile implementation.
Thirdly I expect that we want default vendor profiles to exist. E.g. a
lot of delta between ubuntu & debian can go away / incorporated in
debian source packages if maintainers agree to merge something like
"foo <!vendor-ubuntu>" (boost, e2fsprogs, zsh packages come to mind
among others).
--
Regards,
Dimitri.
Reply to: