Re: [Aptitude-devel] Enquiry about libdpkg-perl alternatives
2016-09-29 03:49 Guillem Jover:
[ Module maintainers and users CCed for lists, and BCCed for people
(where I've omitted those I suspect (?) read the maintainer lists).
Please follow-up on d-dpkg and your maintainer list if relevant. ]
Hi!
I was checking for perl implementations of things provided now by
libdpkg-perl and I see there's several of them, I'd like to canvas the
reasons for the existence of those in case it's due to deficiencies in
libdpkg-perl for example. In the same way, I'm interested in the
reasons the users of those modules had when chosing them instead of
libdpkg-perl?
Also if there's interest, I'm happy to discuss possible missing feature
merge-backs and possible transition handling to deprecate some of the
modules. For example the changelog parsing implementation in libdpkg-perl
was merged a while back from the one in libparse-debianchangelog-perl,
but I think some of the output formatters are still missing there.
[...]
Feedback, much appreciated!
(And after a few month's delay...)
I don't know all of the ramifications of changing one for the other in
aptitude, but there was an earlier attempt to substitute
libparse-debianchangelog-perl for one in dpkg (maybe not "libdpkg-perl",
though, or not in the current state). It was later reverted because of
speed problems and because the tool was part of dpkg-dev (this should
not be applicable in this case).
https://anonscm.debian.org/cgit/aptitude/aptitude.git/commit/?id=36a75bb6d835fee90f896897fd913a2a8faf5c25
https://anonscm.debian.org/cgit/aptitude/aptitude.git/commit/?id=2a9c680fe9dc56e3fb0cec3ad123bc7b2eadd7d2
The relevant bug report is here, but there's not new information:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546280
I wouldn't oppose to change this, in fact I think that it might be a
good idea to use a single tool/library, if possible, and that it's great
that you attempt to reduce the proliferation of tools to achieve the
same result.
However, I am not sure if I'll have much time in the coming months to
work on this or study the advantages of one vs the other, other than
just switching once somebody checks (or at least, has strong
indications) that the substitute will not cause problems.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
Reply to: