On 04/01/2015 11:22 PM, Johan Van de Wauw wrote: > On Wed, Apr 1, 2015 at 10:53 PM, Sebastiaan Couwenberg > <[email protected]> wrote: > >> The CDBS example in the ftp-master REJECT-FAQ is quite similar, but a >> more hidden change than the control file generation done by the rules >> file itself. >> > I was actually talking about: debian/control breakage #2 - ¨Your > package builds binary packages not listed in debian/control > > This is actually the case in the postgis package - the clean target > generating the control file is run at the beginning of the build > (binary or source).
The postgis package indeed doesn't define all binary packages in the control file before the build in all cases, if the postgres version is supported by postgis 2.0 it adds a binary package. This is not in line with the REJECT-FAQ. Because of the dual-life of the postgis source package in Debian and PGAPT I'm not opposed to the current situation, but I'd also like to drop the postgis 2.0 support from the package as soon as possible. I'm not sure how long postgres 9.2 will remain supported, but until then we can't drop the support from the source package without penalizing pgapt. 3rd party apt repositories are a pain in the ass, but pgapt is one of best managed ones causing little to no problems. The postgis 2.0 issue is a good example of ugliness caused by supporting more than just Debian and its derivatives. > I think this is different from the grass situation. For grass - I > think it may be helpful to add a comment in the header of the control > file saying that one should edit the control.in file rather than the > control file itself. Explicitly marking generated control files as such is a good idea, I've been bitten by only updating control but not also control.in more than once too. > Perhaps building a source package should just fail if the result of > control.in generation and control don't match? I'd prefer seeing it > when building the source package then when building the actual package > (or not noticing it at all, as happened to me with saga). The control & control.in files are always different or there would be no need for control.in. I don't think that is a generic check that would work as a sanity check of control vs control.in, most packages just use different versions or dependencies, others conditionally generate binary packages. We definitely needs better guarding against issues related to generated control files, but I don't have any good solutions to offer right now. Perhaps we should review the packages that generate control files on a case-by-case basis to discuss how to improve the situation for each package. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
