Re: Bug#420160: please allow to drop version constraint in B-D when it's in stable
Adeodato Simó <dato@net.com.org.es> writes:
> Package: lintian
> Version: 1.23.29
> Hi.
> I think that the Build-Dep checks that force a specific version of the
> package to be specified should be relaxed once the minimum version is
> available in stable. AIUI, it is ok to drop the version constraint then,
> and many maintainers prefer to do so.
> The one that bit me this time is:
> [ 'quilt (>= 0.40)' => '^include\s+/usr/share/quilt/' ],
I'd like to get some broader input from the developer community on this,
since this affects quite a few lintian checks.
For background, there are numerous checks in lintian that ensure that
dependencies are sufficiently tight to guarantee features used by the
package. Off the top of my head, I know of:
* Depending on a new enough debconf to use error templates or the
SETTITLE command.
* Build-depending on a new enough quilt to have the makefile fragment.
* Build-depending on a new enough python-central or python-support for
proper handling of the new Python policy.
* The Perl version dependency requirements from the Perl policy.
* Pre-depending on a new enough x11-common to let /usr/include/X11 file
installation be safe.
* Build-depending on a new enough gconf for gconf-schemas to be
available.
* Build-depending on a new enough debhelper for the compat level used to
be available.
There are probably more.
In many cases, stable has a new enough version that if we only are
worrying about stable and unstable/testing, the version restrictions could
be dropped. In some cases, this is true even if we include oldstable.
So, what should lintian be doing in this area?
One case of particular interest is how to handle the debconf dependencies
for SETTTILE and error templates. Right now, lintian doesn't allow
packages to depend only on debconf-2.0 if they're using those features
since versions of debconf and/or cdebconf without those features still
provided debconf-2.0. However, all packages in stable that Provide
debconf-2.0 now provide those features. So does the definition of
debconf-2.0 now de facto include those features? Or is an explicit
dependency on specific versions of debconf and cdebconf still needed?
Another case of particular interest is debhelper, where currently lintian
requires a versioned dependency for any compat level higher than 1.
Stable released with debhelper 5, so at least in theory no versioned
dependency is required unless one is using a compat level higher than 5.
But do we want to allow that?
Note that if the stable version of a package is not sufficient to provide
some feature, lintian will still continue to require a versioned
dependency. I think that's important and needs to be preserved. The
question is how far to go back beyond stable.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: