Re: Build-depending on non-free package
On Tue, 02 Sep 2014, Ole Streicher wrote:
> The policy manual says (2.2.2):
>
> | The contrib archive area contains supplemental packages intended to
> | work with the Debian distribution, but which require software outside
> | of the distribution to either build or function.
> ^^^^^^^^^^^^^^^
>
> Which lists a non-free build requirement as its first use case of contrib.
Yeah, but as I said, this doesn't mean it will be autobuildable. It won't
be, at least not yet.
> > Contrib is well-suited to packages that require non-free data. It has
> > always had a problem when there are build-time dependencies on
> > non-free.
>
> 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).
AFAIK, even if ftp-master decides to bless every non-free auto-buildable
package to automatically be an acceptable build-time dependency for contrib,
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.
Chances are it won't happen anytime soon.
> > 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.
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.
3. Get rid of the non-free build-dependency.
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.
This can cause problems for testing migration.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: