Re: Difficult Packaging Practices
- Date: Tue, 28 May 2019 18:57:00 +0000
- From: Niels Thykier <niels@xxxxxxxxxxx>
- Subject: Re: Difficult Packaging Practices
> ❦ 28 mai 2019 06:30 +00, Niels Thykier <niels@xxxxxxxxxxx>:
>> I.e. with the proper implementation of "make-it-work" (in the lack of a
>> better name - maybe something "fetch-and-build"), the following should
>> be possible
>> #!/usr/bin/make -f
>> # DISTRIBUTION = $(shell sed -n "s/^VERSION_CODENAME=//p" /etc/os-release)
>> export VERSION=1.5.16
>> # PACKAGEVERSION = $(VERSION)-0~$(DISTRIBUTION)0
>> export TARBALL = memcached-$(VERSION).tar.gz
>> export URL = https://www.memcached.org/files/$(TARBALL)
>> dh $@ --with make-it-work
>> # override_dh_gencontrol:
>> # dh_gencontrol -- -v$(PACKAGEVERSION)
>> This could inject a tool to run the wget + tar extraction (incl. the
>> distro version sed'ing) after dh_testdir and before
>> dh_update_autotools_config. From there, the dh's standard tools would
>> "just work(tm)" until dh_gencontrol where we have to inject the full
>> version (the commented lines works around that if re-enabled).
>> @Vincent: Do you feel something like this would be helpful, useful and
>> doable? My only reference in the memcached, so the above is tailored to
>> the above.
> That would be very useful as it would reduce the boilerplate but also
> solve some of the problems of hijacking the clean target, notably the
> fact it is executed twice by some tools (like pbuilder, once outside,
> once inside). I didn't propose anything like that as I was thinking it
> was very likely to be rejected as it is of no use for proper Debian
> packages. While my Perl is a bit rusty, I can propose some "dh_fetch"
> helper for this if there is no huge opposition against this approach.
I think it would be fine for a stand-alone debhelper utility/add-on
package to contain such a tool and a dh-sequence to enable it. :) I am
happy with assisting with the technical bits of this utility.
>> Would it help if we could remove the dependency on having a d/changelog
>> (i.e. make it optional)? I have not fully checked if it is doable, but
>> I can look into it if it makes sense and if someone wants to help me
>> test this.
> Yes, it would help too.
I had a stab at it and the results are not too positive. Already before
you reach dh, dpkg-buildpackage goes "I want a d/changelog".
Furthermore, dpkg-gencontrol also insist on a changelog (but the
dh_fetch/dh_uscan tool could have generated it is by then).