Re: Build-depending on non-free package
Henrique de Moraes Holschuh <hmh@debian.org> writes:
>> Sure. The bug #690282 is two years old. All I ask here is how this can
>> be changed, or what the effective way is to support all platforms
>> here -- especially for a DM without abusing his mentor.
>
> It is not trivial to address this request.
>
> It requires manually vetoing which packages from non-free are safe to
> be used as contrib build dependencies (much like we manually veto what
> packages from non-free can be autobuilt).
Why would we need to manually select them?
> AFAIK, even if ftp-master decides to bless every non-free
> auto-buildable package to automatically be an acceptable build-time
> dependency for contrib,
I even don't see why the dependency itself would need to be
auto-buildable. Imagine f.e. a non-free compiler for a specific
language, that exists binary-only (but for a number of Debian
platforms): why should it not automatically selectable as build
dependencies for contrib?
Can you explain why enabling autobuilding for non-free is not as simple
as just adding contrib+non-free to the repository of the build chroot?
For non-free, it is different, since there is no guarantee that there
are source that can be used to build.
> it will likely require autobuilder tooling changes to check for a
> "xs-autobuild: yes" flag when resolving dependencies from non-free, or
> something to that effect.
-v please?
> Chances are it won't happen anytime soon.
I would see this also as a quality assurance tool (much as for the main
distribution): autobuild helps to check the source against quite a
number of platforms and therefore helps to find a lot of bugs.
>> > Actually, for a *long* time we didn't even autobuild anything in
>> > contrib or non-free.
>>
>> So, the first step is done, but not the second?
>
> Yes. To be clear: AFAIK you currently have four choices:
>
> 1. Find a sponsor which will build it on the interesting arches.
.... for every new release. Sounds like a *lot* of work. I personally
would not put such a load to me. Especially since sponsoring is usually
meant that the trainee learns packaging.
> 2. Move it to non-free and get it vetoed as auto-buildable (requires that
> its license and the license of its non-free build-dependencies allow
> this). This isn't really supposed to work, but AFAIK we trust people
> will not abuse it, so it should work.
There is a reason that we have contrib and non-free separated. I must
say that I don't really understand *why* they are separated (is there
any use case to enable contrib, but not non-free or vice versa?), but
since they are, one should not just move from one to the other for
technical reasons, right?
> 3. Get rid of the non-free build-dependency.
There are cases where this impossible. This is the reason why contrib
exists.
> 4. Forget about providing pre-built binary packages for the other arches,
> and write a cookbook for your users to build the binary packages
> themselves from the debian source package.
We want to provide a binary distribution to our end users, and we want
to have best possible experience, right?
Best
Ole
Reply to: