Bug#968000: libconfig-model-dpkg-perl: Get policy release dates in another way

[Axel Beckert]

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 <abe at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/attachments/20220621/3101fccf/attachment.sig>