[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Difficult Packaging Practices



Vincent Bernat:
>  ❦ 28 mai 2019 06:30 +00, Niels Thykier <niels@thykier.net>:
> 
>> 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).

Thanks,
~Niels


Reply to: