Hi, chiming in as the new Lintian maintainer. :-)
Felix Lechner wrote: > Your package is the only known consumer of Lintian's internal Perl > modules. [] I haven't read all the discussion in this bug report, but I stumbled upon it due to these lines in debian/lintian.install: # the next line will be removed when libconfig-model-dpkg-perl stops using Lintian data (Bug#968000) private/latest-policy-version usr/share/lintian/private private/latest-policy-version also seems to be the current way, how libconfig-model-dpkg-perl interacts with this data in Lintian. Actually the fact that this script is used in libconfig-model-dpkg-perl's autopkgtest caused a regression in (or by and for) lintian 2.115.0 because Felix moved one method used in this script from Lintian::Profile to Lintian::Data and forgot to update this script (which Lintian itself doesn't seem to use). So I'll soon upload lintian 2.115.1 to fix this issue to finally get the current Lintian version into testing. On the other it seems as if no lintian-internal check caught this issue, so I'm kinda happy that this has happend. But it also shows what happens if internal modules or so are used. ;-) For a potential long term solution: On #debian-qa, pabs (Cc'ed) was suggesting to the Lintian and DUCK maintainers (Cc'ed as well) to use a common data package for data currently synced occassionally between both source packages. I suggested to build that data out of src:lintian and the duck maintainer was happy with that. Hence I suggest that libconfig-model-dpkg-perl, cme, etc. are then using this planned data packages in the future as well. I currently the following: * Create a new binary package lintian-data, which is built from src:lintian. It will more or less contain /usr/share/lintian/data/. * Additionally I will create a file named /usr/share/lintian/data/debian-policy/latest.txt (or similar) at lintian build time based on the output of private/latest-policy-version. (Can even do that already before splitting off that data package.) That way you have the wanted data in an easily consumable form without having to call any script or module from Lintian and without having to parse a huge bunch of JSON. And we can easily ship that file in a pure data package, not requiring you to pull in all dependencies of Lintian, either. Would that work out for you? If so: What are your requirements for such a transition? Do we have to just care about Unstable and Testing or are Stable-Backports a topic, too? Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
signature.asc
Description: PGP signature