Re: generating debian/control while building source package
On 04/01/2015 11:22 PM, Johan Van de Wauw wrote:
> On Wed, Apr 1, 2015 at 10:53 PM, Sebastiaan Couwenberg
> <sebastic@xs4all.nl> 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
Reply to: