Hi,

Your package is the only known consumer of Lintian's internal Perl
modules. We would like to stop shipping our modules in the Perl system
path. Here is another way to get the information you require.

Your package loads a default Lintian profile [1] and uses the
Lintian::Data mechanism to get the policy release dates from
data/standard-version/release-dates [2]. It may be tempting to use a
simpler parser, but please consider that the information actually
originates somewhere else.

[1] https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-perl/-/blob/master/lib/Config/Model/Dpkg/Control/Source/StandardVersion.pm#L19-23
[2] https://salsa.debian.org/lintian/lintian/-/blob/master/data/standards-version/release-dates

Attached is a script that extracts the release dates from the policy
changelog. It uses the network. The data will always be current.

More information may be available in Bug#903220, which caused you to
use Lintian in the first place.

For some time, Lintian has had issues with outdated modules loading
from the system path. Starting with the next release, Lintian will in
addition ship its Perl modules in a private location.

Please let us know when we can stop shipping our modules in the Perl
system path. Thank you!

Kind regards
Felix Lechner

ok.

Actually, only the latest policy number is used by cme (currently 4.5.0)

I don't really understand your point there, but it may not matter much (see
below)

If the source of information is Salsa, I'd rather use gitlab API to extract
the latest policy version from the tags with something like:

mojo get -r https://salsa.debian.org/api/v4/projects/234/repository/tags \
  /0/name | perl -n -E '/(\d+\.\d+\.\d+)/; say $1;'

Since the data returned by gitlab is JSON, parsing is not much of an issue.

Does that sound reasonable ?

All the best

Hi Dominique,

First of all, thanks for your swift reply!

I have no preference how the package gets the information. I suggested
a solution only in order to appear helpful. Thanks for addressing it
so promptly.

Unless you advise otherwise, Lintian will stop shipping the modules in
the system path in the next release.

As a side note, it seems the changelog date could differ from the tag
date, but that is a question for the policy editors.

Kind regards
Felix Lechner

The problem I see here is that dynamically fetching the policy
version can't work during package builds / for tests; having the
version in a file was the big advantage of using the lintian data.

But yeah, at runtime it should be ok.

Cheers,
gregor

Hi gregor,

I figured. How about depending on debian-policy and using the
information in its changelog?

Kind regards
Felix Lechner

Actually, I could use rmadison to get the latest version of debian-policy
without installing this package (like rmadison is used to get the version of
packages in unstable and older releases)

Please wait until the next release of libconfig-model-dpkg-perl.

All the best

Hi Dominique,

No rush, please. We will keep shipping the modules until you close
this bug. Thank you!

Kind regards
Felix Lechner

But if we skip the test phase that would be ok.

What I'm wondering is:
- depending on debian-policy would be another dependency, and the debian-policy
  only installs files to /usr/share/doc which is not guaranteed to
  exist; and there's also no easily parsable file there;
- will lintian continue to ship
  /usr/share/lintian/data/standards-version/release-dates ? Then we
  could still parse it ourselves without the Lintian perl modules;
- even if lintian ships the perl modules in a private path, it would
  be possible to use it; if this makes sense depends on the reason
  why lintian moves the files, which I haven't fully understood yet
  (my impression is more that this has to do with lintian internales
  like tests that with the question if the modules should be uses by
  others).

But yeah, maybe just using rmadison or whatever other online method
to get the lates S-V is easier than to rely on lintian.


Cheers,
gregor

gregor herrmann <gregoa@debian.org> writes:

If it would be helpful for debian-policy to ship this information directly
in the package, that should be relatively easy to do.  Feel free to open a
bug against debian-policy.  I'm not sure if Sean would see any problems
that I'm not seeing, but I personally have no objection to Policy starting
to install some machine-readable information about Policy in files in
/usr/share/debian-policy in a documented format.

If we did that, I would probably ship this information in YAML rather than
in the somewhat ad hoc format of Lintian's data file (which was my fault
originally).

I think having the data provided by debian-policy (in the package,
and maybe-for other purposes-also on the website) would be an
excellent idea, thanks for the offer.

I'm waiting for Dominique's thoughts before cloning/etc. this bug.


Cheers,
gregor

Agreed. It's better than hitting madison regularly to get policy version.

Please go on.

All the best

Control: clone -1 -2
Control: reassign -2 debian-policy
Control: retitle -2 debian-policy: please provide file with policy release versions and dates
Control: severity -2 wishlist
Control: block -1 with -2
Control: affects -2 + libconfig-model-dpkg-perl

Great.

Thanks for the feedback, doing the BTS control dance now.


Cheers,
gregor

Hi,

I'm not sure what the policy team's intentions are, but Lintian's Data
module no longer provides the policy information. [1] We now keep the
data in a JSON file that is more reliably exchanged and updated. [2]
As a courtesy to this package (and to the policy team) Lintian now
ships an executable "/usr/share/lintian/private/latest-policy-version"
that provides the latest policy information. [3] Please use that
executable to obtain the information you require.

As a side note, Lintian no longer ships its private modules in the
public Perl path. [4] Please do not use our modules directly anymore.
We would be happy to give you access to additional data via
executables, if needed.

Marking this bug "important" because Debian CI is failing (but
separately, since I copied the policy bug). Thanks!

Kind regards
Felix Lechner

[1] https://salsa.debian.org/lintian/lintian/-/commit/d2f692f564ac725a0eb58a7d62abe57f66cdc753
[2] https://salsa.debian.org/lintian/lintian/-/commit/21fd3c7d1ae24bf3bb00ffbab6a0dd99acd3503c
[3] https://salsa.debian.org/lintian/lintian/-/commit/d43799ae30f55e8a211281295d4508b11d022147
[4] https://bugs.debian.org/968011