[Build-common-hackers] Bug#652945: Bug#652945: Atrocious interactions between CDBS, libtool and source format 3.0 (quilt)

[Jonas Smedegaard]

severity 652945 wishlist
thanks

On 11-12-22 at 12:45am, Steve McIntyre wrote:
> Package: cdbs
> Version: 0.4.100
> Severity: grave
> Justification: zero documentation, wasting hours of development time, causing many bugs
> 
> I've just wasted multiple hours trying to fix up the mess in an NMU
> (#652369). That bug itself isn't necessarily caused by CDBS itself,
> but a lot of the time I've spent trying to fix it definitely is.

(note for later: that was 1 (one) bug, _not_ caused by CDBS)


> I've just had to update the dvbstreamer package's local copy of 
> libtool to make it build binaries in a current unstable chroot. After 
> fighting through the CDBS code to decipher how to do that (yay for 
> total lack of documentation!), I've found DEB_AUTO_UPDATE_LIBTOOL that 
> seems to do what I need.

True, CDBS currently lacks formal documentation.


> Unfortunately, it doesn't take copies of any of the existing upstream 
> files to be able to put them back during a "debian/rules clean" run. 
> That means that dpkg-source v3 (quilt) bitches and refuses to run 
> again once I've done a build due to uncommitted changes.

True, DEB_AUTO_UPDATE_LIBTOOL helps you update Libtool, but does not 
help you restore during clean.

You may also find dh-autoreconf useful.  I am unaware if it works alone 
or is entangled with short-form "dh" these days.

Contrary to common misconception, CDBS does not conflict with debhelper 
but complements it.  Short-form "dh" debhelper syntax conflicts with 
CDBS, though.


> Hence, I can't tweak things and re-run dpkg-buildpackage/debuild while 
> debugging things (as already complained about elsewhere this week).

Wrong: CDBS only helping you partly does not mean that you "can't tweak 
things".


> I've looked in vain for any way to make this work, but cannot find 
> one.

Not sure where you looked in vain (yes, you already mentioned that 
documentation i lacking so obviously I expect you to be talking about 
something else - not repeating yourself!).  What I typically do is look 
at other CDBS-using packages for inspiration.  Try look at liblrdf, it 
does little other tweaking than regenerating autotools incl. Libtool.


> Therefore, I'm about to upload my new NMU with working packages
> but (as far as I'm concerned) a buggy build system that will reliably
> fail to build twice in a row. If this wasn't an NMU and therefore I
> wasn't trying to keep changes minimal, I would be fixing the package
> more deeply by repackaging it without CDBS.
> 
> Please remove this under-documented and badly-designed rubbish from
> the archive. It's been responsible for bad maintainer behaviour and
> lots of RC bugs in the past, and I can see this happening again and
> again in future.

Apart from lack of documentation (reported already in bug#649151), the 
"causing many bugs" really is one bug which you yourself describe as not 
caused by CDBS.  I therefore consider this a rant and a wish for CDBS to 
disappear, and have lowered severity accordingly.


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20111222/39b4fd5d/attachment.pgp>