Re: Bug#420160: please allow to drop version constraint in B-D when it's in stable

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Bug#420160: please allow to drop version constraint in B-D when it's in stable

Russ Allbery-2
Adeodato Simó <[hidden email]> 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 ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: Bug#420160: please allow to drop version constraint in B-D when it's in stable

Loïc Minier
On Wed, Apr 25, 2007, Russ Allbery wrote:
> I'd like to get some broader input from the developer community on this,
> since this affects quite a few lintian checks.

 I think the provided information is still valuable at some level (for
 example it could be useful to people backporting to oldstable or
 maintaining derivatives), but it would sound incorrect to report these
 at the "warning" level: perhaps you can report them at a lower level
 and/or permit enabling this class of checks via configuration?

--
Loïc Minier


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bug#420160: please allow to drop version constraint in B-D when it's in stable

Russ Allbery-2
Loïc Minier <[hidden email]> writes:
> On Wed, Apr 25, 2007, Russ Allbery wrote:

>> I'd like to get some broader input from the developer community on
>> this, since this affects quite a few lintian checks.

>  I think the provided information is still valuable at some level (for
>  example it could be useful to people backporting to oldstable or
>  maintaining derivatives), but it would sound incorrect to report these
>  at the "warning" level: perhaps you can report them at a lower level
>  and/or permit enabling this class of checks via configuration?

This would be nice, but I probably should have mentioned in my previous
message that lintian's internal architecture makes this rather difficult
for many of these checks.  In some cases it wouldn't be too bad to add the
additional check at info level, but in other cases it would require
developing some new infrastructure to run separate info-level checks.

I'm not entirely sure the maintenance burden warrants it, although in the
long run I do want to do tag-filtered reports from lintian so that one can
selectively enable pickier tags.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: Bug#420160: please allow to drop version constraint in B-D when it's in stable

Steve Langasek
In reply to this post by Russ Allbery-2
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.
[hidden email]                                   http://www.debian.org/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bug#420160: please allow to drop version constraint in B-D when it's in stable

Russ Allbery-2
Steve Langasek <[hidden email]> writes:

> 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?

Okay, that's two votes for dropping it to I.  :)  I'll take a closer look
at what would be involved in adding the infrastructure to keep the
warnings around at the I level for oldstable stuff.  It should be easy
with debconf and x11-common and relatively easy with debhelper.  quilt and
a few other things will be harder, but I may drop those if I don't see an
easy way of doing it.

Any reason to keep anything around for versions prior to oldstable, or
should that just go away?

> 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.

Yup, that's my feeling on it too.

> 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?

Yes, that would be very nice.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bug#420160: please allow to drop version constraint in B-D when it's in stable

Joey Hess
In reply to this post by Steve Langasek
Steve Langasek wrote:
> (BTW, why was 'settitle' not included in the output of the 'CAPB' command?
> Seems like it should have been?)

Because settitle support can be tested for by trying to use the command and
checking for a result code of 20.

--
see shy jo

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug#420160: please allow to drop version constraint in B-D when it's in stable

Steve Langasek
In reply to this post by Russ Allbery-2
On Wed, Apr 25, 2007 at 01:54:27PM -0700, Russ Allbery wrote:

> Okay, that's two votes for dropping it to I.  :)  I'll take a closer look
> at what would be involved in adding the infrastructure to keep the
> warnings around at the I level for oldstable stuff.  It should be easy
> with debconf and x11-common and relatively easy with debhelper.  quilt and
> a few other things will be harder, but I may drop those if I don't see an
> easy way of doing it.

> Any reason to keep anything around for versions prior to oldstable, or
> should that just go away?

IMHO it should just go away.  I don't think unstable is even remotely
suitable as a basis for development for stable-2, so there's no reason
anyone should be running the unstable lintian if they're developing for
woody (heh).

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.
[hidden email]                                   http://www.debian.org/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bug#420160: please allow to drop version constraint in B-D when it's in stable

Steve Langasek
In reply to this post by Joey Hess
On Thu, Apr 26, 2007 at 01:59:04PM -0400, Joey Hess wrote:
> Steve Langasek wrote:
> > (BTW, why was 'settitle' not included in the output of the 'CAPB' command?
> > Seems like it should have been?)

> Because settitle support can be tested for by trying to use the command and
> checking for a result code of 20.

Ah, good enough -- so SETTITLE shouldn't require a versioned dep on debconf
anyway, it's only the use of the new 'error' template type that requires
this.

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.
[hidden email]                                   http://www.debian.org/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]