hello piuparts maintainers, as you might know, adequate(1) has been rewritten from scratch last July. the rewrite is meant to be a [drop-in] replacement, with only very trivial backwards-incompatible changes (see /usr/share/doc/adequate/NEWS.Debian.gz for full details)
I'm told that piuparts.d.o runs on Debian stable, and therefore still relies on
the old implementation of adequate. Holger has suggested that it'd be good to
try out the new implementation in piuparts.d.o (perhaps in a test instance, if
one exists) prior to the Trixie release.
I'm not particularly worried (adequate has not received any bug reports in the
last few months, and all of the reports that were filed shortly after the
rewrite have been long addressed) but I see no reason why we shouldn't give
Holger's suggestion a try. (I'd go even further and suggest that piuparts.d.o
should always use adequate from testing but I'd rather leave that for another
thread, if you see that as a contentious change). as a one off, we could
temporarily pin adequate to the testing release, or manually install the
adequate executable from testing/unstable (adequate's Depends in
testing/unstable are satisfied by bookworm)
I'm happy to carry out the aforementioned testing myself, but I'd need somebody
to answer questions regarding the piuparts.d.o setup (given that, trivial
changes aside, piuparts/docs/README_pejacevic.txt has been written 5y ago) and
would need access to at least one piuparts runner instance.
once we establish that all's good, I'd also like to discuss the possibility of
overriding --fail-if-inadequate to true in piuparts.d.o, or even changing the
default in piuparts.py
thanks,
serafi
[drop-in] the rewritten adequate is not available in three ports; my
understanding is that that should be immaterial given that all
piuparts runners run on amd64
signature.asc
Description: PGP signature
