FS#60246 - [libafterimage] May not package headers

Attached to Project: Community Packages
Opened by Konstantin Gizdov (kgizdov) - Saturday, 29 September 2018, 17:32 GMT
Last edited by Felix Yan (felixonmars) - Thursday, 21 February 2019, 20:09 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
This package was taken over from AUR and put here without taking into account several comments to fix it. Package currently contains a bug in the shipped Makefile. The 'install.inc' directive runs as part of 'make install' and does not always complete correctly. In fact it does not complete every other time - high risk of mispackaging.


Steps to reproduce:
- build & package
- build & package again
This task depends upon

Closed by  Felix Yan (felixonmars)
Thursday, 21 February 2019, 20:09 GMT
Reason for closing:  Fixed
Additional comments about closing:  in trunk
Comment by Konstantin Gizdov (kgizdov) - Sunday, 30 September 2018, 02:10 GMT
I'm pretty sure that must be incorrect. There is a bug in the Makefile and if you build it several times in a row, the build is not reproducable, even in a clean environment. I've had to patch this in my CIs - I depend on this package.
Comment by Eli Schwartz (eschwartz) - Sunday, 30 September 2018, 02:16 GMT
This is a legitimate bug. The Makefile creates every directory with mkdir -p, except for the includedir -- so depending on which order GNU Make decides to run the weirdly segmented multi-target install process, `mkdir $(DESTDIR)/usr/include` will fail.

This non-deterministically results in the whole headers install failing. Worse, the build system inexcusably considers this *okay* and echoes "failed to create include directory", then happily continues installing the libs/programs while pretending everything is okay.
Comment by Doug Newgard (Scimmia) - Sunday, 30 September 2018, 04:01 GMT
I was going by the information stated in the report: "In fact it does not complete every other time"

If that's not correct, then yes, it's a race condition that's potentially a problem.
Comment by Felix Yan (felixonmars) - Sunday, 30 September 2018, 04:58 GMT
I have made a simple patch to add "-p" to those mkdir calls, and tried several builds with successful header installation. Since the binary package is currently not affected I have only committed the change to trunk. Please let me know if it needs additional adjustments.
Comment by Eli Schwartz (eschwartz) - Sunday, 30 September 2018, 05:34 GMT
(another fix would be mkdir -p "${pkgdir}"/usr/include before running make install)

Yes, building it again with the current version produces the following output:

==> Starting package()...
/usr/bin/mkdir -p /build/libafterimage/pkg/libafterimage/usr/include
/usr/bin/mkdir -p /build/libafterimage/pkg/libafterimage/usr/include/libAfterImage
installing libAfterImage headers using command -
"/usr/bin/install -c -m 644 <header> /build/libafterimage/pkg/libafterimage/usr/include/libAfterImage" :
afterimage.h afterbase.h /usr/bin/install -c -m 755 libAfterImage.so.0.99 /build/libafterimage/pkg/libafterimage/usr/lib
ascmap.h asfont.h asim_afterbase.h asimage.h asimagexml.h asstorage.h asvisual.h blender.h bmp.h char2uni.h draw.h export.h imencdec.h import.h pixmap.h scanline.h transform.h ungif.h xcf.h ximage.h xpm.h xwrap.h

This is the race condition right here, and it's solved.

(There's also the issue where #include "config.h" and their terrible ".depend" file results in every make call thinking it needs to rebuild the apps/ folder, so package() will recompile them all. But eh.)

Loading...