Re: Bug#420160: please allow to drop version constraint in B-D when it's in stable
On Wed, Apr 25, 2007 at 01:09:30PM -0700, Russ Allbery wrote:
> 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?
There's an 'informational' level below 'warning' in lintian, right? Perhaps
versioned deps that are only relevant to oldstable could be dropped from W/E
to I?
The reason I think this is advisable is that the net impact of not having
the versioned dep is approximately zero, and many maintainers give a high
priority to having lintian-clean packages. In the absence of particular
user demand for oldstable backports, I think their time is better spent
elsewhere than on this class of error.
> 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?
>From a releasability standpoint, the fact that SETTITLE and error templates
are now supported by all implementors of debconf in stable means that an
explicit dependency is no longer needed. But I don't imagine this is the
last extension that will ever be added to debconf, so wouldn't it be nice if
the debconf implementors would agree on additional virtual packages to
provide as each new extension comes along? E.g., Provides: debconf-2.0,
debconf-error, or Provides: debconf-2.0, debconf-2.0.1?
(BTW, why was 'settitle' not included in the output of the 'CAPB' command?
Seems like it should have been?)
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: