Bug#888949: libconfig-model-dpkg-perl: recognize X{S,B}-Ruby-Versions field for packages depending on ruby, not only ruby section

[Dominique Dumont]

On Wednesday, 4 April 2018 22:20:08 CEST Cédric Boutillier wrote:
> So I think "build-depend on gem2deb" would be
> the best criterion.
> 
> Now a decision based on the Maintainer field would possibly cover more
> than 95% of the cases already, with (almost?) no false positive.

Well, the fact that XS-Ruby-Version pops in or out depending on the value of a 
parameter is based on a mechanism that does not support checking the content 
of a list. This would require quite a change in the core Config::Model 
library. That's why I proposed using Maintainer field.

Let's try the easy way, i.e. using Maintainer field.

If this cause too much problems, I'll see what I can do to use a build-depend 
item.

Is this fine with you ?

All the best

Bug#888949: libconfig-model-dpkg-perl: recognize X{S,B}-Ruby-Versions field for packages depending on ruby, not only ruby section

[Cédric Boutillier]

Sure, thanks!

Bug#888949: libconfig-model-dpkg-perl: recognize X{S,B}-Ruby-Versions field for packages depending on ruby, not only ruby section

[Cédric Boutillier]

> How about basing this decision on the Maintainer field ? (which would 
> probably 
> be more reliable than basing the decision on the presence of a dependency)

The XS-Ruby-Version is used (only?) by dh_ruby provided by the gem2deb
package. I think this behaviour would be useful also for packages not
maintained by the Ruby team, and they have a higher probability to not
be in the ruby section. So I think "build-depend on gem2deb" would be
the best criterion.

Now a decision based on the Maintainer field would possibly cover more
than 95% of the cases already, with (almost?) no false positive.

Cheers,

Cédric


signature.asc
Description: PGP signature

Bug#888949: libconfig-model-dpkg-perl: recognize X{S,B}-Ruby-Versions field for packages depending on ruby, not only ruby section

[Dominique Dumont]

On Wed, 31 Jan 2018 15:01:33 +0100 =?utf-8?Q?C=C3=A9dric?= Boutillier 
 wrote:
> The spectrum of ruby packages in Debian became wider some of the
> packages, though they use gem2deb and make use of these variables, are
> not in the ruby section of the archive. Such an example is nanoc, a
> static website generator (and thus in the web section).

Makes sense.

> Running cme fix dpkg-control on nanoc results in a no-op since the
> variable XS-Ruby-Versions is not recognized.
> Could you please widen the criteria for packages for which these fields are 
recognized?
> (like those depending on ruby or rather build-depending on gem2deb?)

How about basing this decision on the Maintainer field ? (which would probably 
be more reliable than basing the decision on the presence of a dependency)

All the best

Bug#888949: libconfig-model-dpkg-perl: recognize X{S,B}-Ruby-Versions field for packages depending on ruby, not only ruby section

[Cédric Boutillier]

Package: libconfig-model-dpkg-perl
Version: 2.105
Severity: minor

Dear Maintainer,

For a few years now, cme recognizes the X{S,B}-Ruby-Versions fields in
debian/control for packages of the ruby section.
Thanks a lot for that.

The spectrum of ruby packages in Debian became wider some of the
packages, though they use gem2deb and make use of these variables, are
not in the ruby section of the archive. Such an example is nanoc, a
static website generator (and thus in the web section).

Running cme fix dpkg-control on nanoc results in a no-op since the
variable XS-Ruby-Versions is not recognized.
Could you please widen the criteria for packages for which these fields are 
recognized?
(like those depending on ruby or rather build-depending on gem2deb?)

Thank you in advance.

Cédric



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libconfig-model-dpkg-perl depends on:
ii  libapt-pkg-perl  0.1.33
ii  libarray-intspan-perl2.003-1
ii  libconfig-model-perl 2.116-1
ii  libexporter-lite-perl0.08-1
ii  liblog-log4perl-perl 1.49-1
ii  libmouse-perl2.5.1-1
ii  libparse-recdescent-perl 1.967015+dfsg-1
ii  libsoftware-license-perl 0.103012-1
ii  libtext-autoformat-perl  1.74-2
ii  libtext-levenshtein-damerau-perl 0.41-1
ii  liburi-perl  1.73-1
ii  libwww-perl  6.31-1
ii  libyaml-perl 1.24-1
ii  licensecheck 3.0.31-2
ii  lintian  2.5.72
ii  perl 5.26.1-4
ii  perl-modules-5.26 [libmodule-corelist-perl]  5.26.1-4

Versions of packages libconfig-model-dpkg-perl recommends:
ii  libconfig-model-tkui-perl  1.365-1

libconfig-model-dpkg-perl suggests no packages.

-- no debconf information