Adeodato Simó <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
