Re: Difficult Packaging Practices
- Date: Tue, 28 May 2019 06:30:00 +0000
- From: Niels Thykier <niels@xxxxxxxxxxx>
- Subject: Re: Difficult Packaging Practices
> ❦ 28 mai 2019 08:59 +08, Paul Wise <pabs@xxxxxxxxxx>:
>>> People using tools like fpm will never get familiar with our tools and
>>> will never be contributors.
>> I enjoyed your blog post about pragmatic packaging using Debian's
>> tools instead of fpm, it seems like a good approach if one is
>> committed to using Debian, especially since it allows for incremental
>> improvement towards a package that could even enter Debian.
>> OTOH I get the feeling that most FLOSS upstreams are interested in
>> cross-OS and cross-distro packaging rather than Debian-specific
>> packaging. I don't have a good feeling for how "sticky" OS/distro
>> choices are for folks who are building non-FLOSS services on top of
>> FLOSS distros.
> Yes, upstreams are more likely to prefer one tool. However, if you
> contribute a native implementation that works accross the same set of
> Debian-derivative distributions, in my experience, they are usually
> eager to accept it it stays simple enough to not be a maintenance
> burden. Of course, it helps if they didn't start with fpm.
It seems to me that it should be doable to write one or two helper tools
that could handle the fetch and then pass the downloaded code on to
dh_auto_* which would then DTRT (in case of standard build systems).
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
# DISTRIBUTION = $(shell sed -n "s/^VERSION_CODENAME=//p" /etc/os-release)
# PACKAGEVERSION = $(VERSION)-0~$(DISTRIBUTION)0
export TARBALL = memcached-$(VERSION).tar.gz
export URL = https://www.memcached.org/files/$(TARBALL)
dh $@ --with make-it-work
# 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
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