Henrique de Moraes Holschuh <h...@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 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87tx4qc9kc....@news.ole.ath.cx
