Bug#727610: debian-policy: clearer discussion of why build-indep implies building the whole package
On Sat, 26 Oct 2013 14:14:23 +0200 Guillem Jover guil...@debian.org wrote: Hi! On Thu, 2013-10-24 at 15:47:56 +0100, Ximin Luo wrote: Package: debian-policy Severity: normal I was recently told to split part of my Build-Depends field into a separate Build-Depends-Indep field. Not one to follow orders without question, I went and did some research, and found this snippet in the policy[1]: There is no Build-Depends-Arch; this role is essentially met with Build-Depends. Anyone building the build-indep and binary-indep targets is assumed to be building the whole package, and therefore installation of all build dependencies is required. dpkg has supported Build-Depends-Arch and Build-Conflicts-Arch since 1.16.4 (complete support with 1.17.0). Although they should not be used yet, as long as other resolvers are not aware of these. Thanks, Guillem Hi Policy maintainers, With dpkg and buildds supporting build-arch and build-indep plus source uploads being tested in unstable, perhaps it is time to move forward with this again? :) The build options are currently: 1. Maintainer uses binary and build targets (i.e. *-arch AND *-indep) - buildds uses binary-arch and build-arch missing architectures 2. Maintainer uses binary-indep and build-indep targets - buildds uses binary-arch and build-arch on *every* architecture (Ben Hutching has been doing this for a while already) 3. Maintainer uploads a source only (*) - One buildd uses binary-indep and build-indep to build the arch:all packages (if present) - buildds uses binary-arch and build-arch on *every* architecture (*): Being tested in experimental atm., As noted, only option 1 uses the binary and build target. Thanks, ~Niels Please CC me on replies. signature.asc Description: OpenPGP digital signature
Re: debian/copyright in source package
On Tue, 25 Aug 2015, Santiago Vila wrote: On Sun, 23 Aug 2015, Thorsten Alteholz wrote: But policy says that there should be such a copyright file. Violating such a clause is at least an important bug. I guess you refer to policy when it says that we could match must with serious and should with important. yes However, the BTS documentation says that important means a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. Not having a debian/copyright file in the source package does not affect usability of the package in *any* way. If it is not possible to add the copyright and license information to the binary package, it might violate some licenses and such the package may not be distributed by Debian or may not be used on Debian systems. As the normal workflow of packaging is to collect the copyright and license information in debian/copyright and copy that file into the binary package during build, a missing file might make the package unusable. Of course, not in a technical manner. Anyway, in the light of source only uploads, how shall the copyright and license information of the binary packages be verified, if there is no debian/copyright? Either the maintainer or the ftpteam has to do the work. Given that the package output of about 1000 maintainers needs to be checked by just a few members of the ftpteam, the burden should be distributed on the larger group. And experience shows that there is a check needed to fulfill the DFSG. Thorsten
Re: debian/copyright in source package
On Wed, Aug 26, 2015 at 11:14:48PM +0200, Thorsten Alteholz wrote: On Tue, 25 Aug 2015, Santiago Vila wrote: Not having a debian/copyright file in the source package does not affect usability of the package in *any* way. If it is not possible to add the copyright and license information to the binary package, it might violate some licenses and such the package may not be distributed by Debian or may not be used on Debian systems. As the normal workflow of packaging is to collect the copyright and license information in debian/copyright and copy that file into the binary package during build, a missing file might make the package unusable. Of course, not in a technical manner. I think you are missing the point completely. I'm talking about packages shipping *proper* copyright files in their .deb that are generated by debian/rules at build time. There is absolutely no license, copyright or dfsg-freeness problem in doing that, and there is also no usability problem at all justifying the important severity. Moreover, normal workflow != mandatory. If you want to make it mandatory, what you should do is to modify policy so that it reads must, not submitting a lot of similar bugs with inflated severity. Anyway, in the light of source only uploads, how shall the copyright and license information of the binary packages be verified, if there is no debian/copyright? Either the maintainer or the ftpteam has to do the work. Given that the package output of about 1000 maintainers needs to be checked by just a few members of the ftpteam, the burden should be distributed on the larger group. And experience shows that there is a check needed to fulfill the DFSG. If that's really a problem, I think it would be fair to require that the very first time a package is uploaded, it's *not* done in source-only form. This way you will always have a copyright file available without having to build the package yourself. But there is something I don't understand. Do you *just* verify that there is a debian/copyright file in the source? You don't verify that it matches the actual copyright notices in the several *.c files etc? Surely that a mandatory debian/copyright file in the source might simplify your work a little bit (which is why you should try to modify policy in the first place), but such kind of help would be just a small fraction of the license and copyright checking anyway. So, to summarize, I don't think this is such a big problem.
!! Establezca una comunicación DIRECTA y EFECTIVA con miles Clientes ¡¡
Si no puedes visualizar este email corectamente, Haz clic aquí para verlo en la web. Agrega a contacte...@leonagencies.com a tu lista de contactos. Planes SMS Establezca una comunicación directa e inmediata con sus clientes. En León Agencies te ayudamos a enviar mensajes masivos a un sin número de clientes potenciales. Adquiriendo un plan de mensajería masiva podrá llegar a gran cantidad de usuarios a quienes podrá dar a conocer información que desee promocionar de su empresa. Optimice su presupuesto con una comunicación efectiva a bajo costo. ¡Envía un SMS ya! Si deseas dejar de recibir nuestras ofertas, haz clic aquí
