Debian Bug report logs - #758425
lintian: Add a check for outdated version constraints

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Johannes Schauer <[email protected]>

To: Debian Bug Tracking System <[email protected]>

Subject: lintian: add a check for outdated version constraints

Date: Sun, 17 Aug 2014 14:38:10 +0200

Package: lintian
Version: 2.5.25
Severity: wishlist

Hi,

Lintian could check if any dependency on binary packages has an outdated
version constraint. If the outdated version constraint is attached to an
essential package, then the dependency can be dropped completely. This
will then avoid useless triggering of autopkgtests for those packages.
If the dependency is not essential then the version constraint can be
removed. The check whether a version is outdated can easily be done by
having a data file with package name and its version in oldstable. If
the version constraint points to a version prior to oldstable then the
constraint can be dropped or the dependency dropped if it is essential.

cheers, josch

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils                       2.24.51.20140617-1
ii  bzip2                          1.0.6-5
ii  diffstat                       1.58-1
ii  file                           1:5.19-1
ii  gettext                        0.18.3.2-3
ii  hardening-includes             2.5
ii  intltool-debian                0.35.0+20060710.1
ii  libapt-pkg-perl                0.1.29+b1
ii  libarchive-zip-perl            1.37-2
ii  libclass-accessor-perl         0.34-1
ii  libclone-perl                  0.37-1
ii  libdpkg-perl                   1.17.13
ii  libemail-valid-perl            1.194-1
ii  libfile-basedir-perl           0.03-1
ii  libipc-run-perl                0.92-1
ii  liblist-moreutils-perl         0.33-2
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtext-levenshtein-perl       0.09-1
ii  libtimedate-perl               2.3000-2
ii  liburi-perl                    1.62-1
ii  man-db                         2.6.7.1-1
ii  patchutils                     0.3.3-1
ii  perl [libdigest-sha-perl]      5.18.2-6
ii  t1utils                        1.37-2

Versions of packages lintian recommends:
ii  libautodie-perl                 2.25-1
ii  libperlio-gzip-perl             0.18-3
ii  perl-modules [libautodie-perl]  5.18.2-6

Versions of packages lintian suggests:
pn  binutils-multiarch     <none>
ii  dpkg-dev               1.17.13
ii  libhtml-parser-perl    3.71-1+b1
ii  libtext-template-perl  1.46-1
ii  libyaml-perl           0.95-1
ii  xz-utils               5.1.1alpha+20120614-2

-- no debconf information

Message #10 received at [email protected] (full text, mbox, reply):

From: Raphael Hertzog <[email protected]>

To: Johannes Schauer <[email protected]>, [email protected]

Subject: Re: Bug#758425: lintian: add a check for outdated version constraints

Date: Fri, 29 Aug 2014 21:16:06 +0200

On Sun, 17 Aug 2014, Johannes Schauer wrote:
> Lintian could check if any dependency on binary packages has an outdated
> version constraint. If the outdated version constraint is attached to an
> essential package, then the dependency can be dropped completely. This
> will then avoid useless triggering of autopkgtests for those packages.
> If the dependency is not essential then the version constraint can be
> removed. The check whether a version is outdated can easily be done by
> having a data file with package name and its version in oldstable. If
> the version constraint points to a version prior to oldstable then the
> constraint can be dropped or the dependency dropped if it is essential.

If that is ever implemented, it must apply only on dependencies
that can be parsed on the source's debian/control because I would
not be happy to have warnings on library dependencies generated
by dpkg-shlibdeps.

Also there are quite a few maintainers that believe that correct
information don't do much harm and I have a hard time justifying this
change just for the purpose of bootstrapping a new port. The point
9.1 in
http://lists.debian.org/[email protected] only
mentions "compiler dependencies" so maybe this can be restricted
to a smaller subset (or maybe be an "I" by default but a "W" on
the packages where it matters?).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

Message #15 received at [email protected] (full text, mbox, reply):

From: Johannes Schauer <[email protected]>

To: Raphael Hertzog <[email protected]>, [email protected]

Subject: Re: Bug#758425: lintian: add a check for outdated version constraints

Date: Fri, 29 Aug 2014 21:32:45 +0200

Hi,

Quoting Raphael Hertzog (2014-08-29 21:16:06)
> If that is ever implemented, it must apply only on dependencies that can be
> parsed on the source's debian/control because I would not be happy to have
> warnings on library dependencies generated by dpkg-shlibdeps.

How can it happen that library dependencies generated by dpkg-shlibdeps create
a dependency on a package version older than in old stable?

> Also there are quite a few maintainers that believe that correct information
> don't do much harm and I have a hard time justifying this change just for the
> purpose of bootstrapping a new port. The point 9.1 in
> http://lists.debian.org/[email protected] only
> mentions "compiler dependencies" so maybe this can be restricted to a smaller
> subset (or maybe be an "I" by default but a "W" on the packages where it
> matters?).

You mean the sentence "Versioned dependencies are problematic for bootstrapping
because versioned compiler dependencies have to be translated and the versions
of binary packages is not known a priori during a bootstrap from zero."

I agree that in retrospect this was not well formulated. There are two issues
where versioned dependencies create problems for bootstraps. One is versioned
compilers because they have to be translated to their cross variant when cross
compiling. The other is all other "versions of binary packages" because they
have to be associated to source packages but it cannot be known from which
version of a source package they build.

On the other hand:

1. If the solution proposed in section 4.1. is uploaded and it turns out that
   it works actually as reliably as imagined, then translating versioned
   compiler dependencies will be no problem. It would just mean that those who
   want to keep their build dependency on gcc (>= 2.95.2) have to change that
   dependency to gcc-for-build (>= 2.95.2) and/or gcc-for-host (>= 2.95.2) as
   applicable.

2. In case of versioned dependencies on binary packages greater than
   pre-oldstable, falling back to the latest source version will not have any
   differently bad side effects compared to versioned dependencies on binary
   packages greater than or equal to oldstable.

So if (1.) happens to work out, there indeed does not seem to be a strong
reason left to have lintian warn about ancient versions. The only other reason
I can think of would be that it produces a tiny slowdown to dependency
resolvers but that is of course also not a very strong reason.

cheers, josch

Message #20 received at [email protected] (full text, mbox, reply):

From: Raphael Hertzog <[email protected]>

To: Johannes Schauer <[email protected]>

Cc: [email protected]

Subject: Re: Bug#758425: lintian: add a check for outdated version constraints

Date: Fri, 29 Aug 2014 22:17:43 +0200

On Fri, 29 Aug 2014, Johannes Schauer wrote:
> Hi,
> 
> Quoting Raphael Hertzog (2014-08-29 21:16:06)
> > If that is ever implemented, it must apply only on dependencies that can be
> > parsed on the source's debian/control because I would not be happy to have
> > warnings on library dependencies generated by dpkg-shlibdeps.
> 
> How can it happen that library dependencies generated by dpkg-shlibdeps create
> a dependency on a package version older than in old stable?

When a library has a symbols file that has evolved over more than 2
releases (like libc6)... see /var/lib/dpkg/info/libc6:amd64.symbols it
references versions as old as 2.2.5 when oldstable currently has 2.11.

> You mean the sentence "Versioned dependencies are problematic for bootstrapping
> because versioned compiler dependencies have to be translated and the versions
> of binary packages is not known a priori during a bootstrap from zero."

Yes.

> compiling. The other is all other "versions of binary packages" because they
> have to be associated to source packages but it cannot be known from which
> version of a source package they build.

This is a wrong problem given that in the majority of the case a given binary
package will only be produced by a single source package. The binary
package might be referenced multiple times in some rare cases of binary packages
moving between source packages but I hardly doubt that this is a serious
problem for bootstrapping a new architecture. It doesn't happen that
often.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

Message #25 received at [email protected] (full text, mbox, reply):

From: Johannes Schauer <[email protected]>

To: Raphael Hertzog <[email protected]>,

Cc: [email protected]

Subject: Re: Bug#758425: lintian: add a check for outdated version constraints

Date: Fri, 29 Aug 2014 22:23:04 +0200

Hi,

Quoting Raphael Hertzog (2014-08-29 22:17:43)
> When a library has a symbols file that has evolved over more than 2 releases
> (like libc6)... see /var/lib/dpkg/info/libc6:amd64.symbols it references
> versions as old as 2.2.5 when oldstable currently has 2.11.

Right.

> > compiling. The other is all other "versions of binary packages" because
> > they have to be associated to source packages but it cannot be known from
> > which version of a source package they build.
> 
> This is a wrong problem given that in the majority of the case a given binary
> package will only be produced by a single source package. The binary
> package might be referenced multiple times in some rare cases of binary packages
> moving between source packages but I hardly doubt that this is a serious
> problem for bootstrapping a new architecture. It doesn't happen that
> often.

If it is valued highly to even keep version constraints from before oldstable,
then I propose to:

 - only check the manual dependencies from debian/control (and not those
   generated by dpkg-shlibdeps because those are legit)

 - restrict the set of packages for which to warn to those that have to be
   translated (compilers). The warning could then point out that the developer
   can either drop the versioned dependency or format the build dependencies so
   that they get properly translated during cross compilation.

This also means that fixing this bug has to wait until cross compiler
translation arrives in main.

Would this course of action be acceptible?

cheers, josch

Message #30 received at [email protected] (full text, mbox, reply):

From: Raphael Hertzog <[email protected]>

To: Johannes Schauer <[email protected]>

Cc: [email protected]

Subject: Re: Bug#758425: lintian: add a check for outdated version constraints

Date: Fri, 29 Aug 2014 23:42:42 +0200

On Fri, 29 Aug 2014, Johannes Schauer wrote:
>  - only check the manual dependencies from debian/control (and not those
>    generated by dpkg-shlibdeps because those are legit)

Definitely.

>  - restrict the set of packages for which to warn to those that have to be
>    translated (compilers). The warning could then point out that the developer
>    can either drop the versioned dependency or format the build dependencies so
>    that they get properly translated during cross compilation.
>
> Would this course of action be acceptible?

I'd say yes but I don't know how you define the set of packages. How can
lintian know if a package is a compiler?

> This also means that fixing this bug has to wait until cross compiler
> translation arrives in main.

Not sure I understand what this means. Perhaps it refers to some
meta-information that will help to identify the compilers?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

Message #35 received at [email protected] (full text, mbox, reply):

From: Johannes Schauer <[email protected]>

To: Raphael Hertzog <[email protected]>,

Cc: [email protected]

Subject: Re: Bug#758425: lintian: add a check for outdated version constraints

Date: Sat, 30 Aug 2014 06:57:15 +0200

Hi,

Quoting Raphael Hertzog (2014-08-29 23:42:42)
> I'd say yes but I don't know how you define the set of packages. How can
> lintian know if a package is a compiler?

By carrying a list of packages that need translation when cross compiling.

> > This also means that fixing this bug has to wait until cross compiler
> > translation arrives in main.
> 
> Not sure I understand what this means. Perhaps it refers to some
> meta-information that will help to identify the compilers?

Fixing this bug has to wait until the package layout shown in point 4.1. in [1]
is generated by src:gcc-cross-support. This will not help identifying what is a
compiler though. That information would have to be updated in Lintian every
time a new compiler binary package lands in the archive.

cheers, josch

[1] https://lists.debian.org/debian-devel-announce/2014/08/msg00013.html

Message #42 received at [email protected] (full text, mbox, reply):

From: [email protected] (Apache)

To: [email protected]

Subject: Notification status of your delivery (UPS 008536322)

Date: Fri, 24 Feb 2017 02:00:29 +0100

[Message part 1 (text/plain, inline)]

Dear Customer,

UPS courier was unable to contact you for your parcel delivery.

Review the document that is attached to this e-mail!

Thanks,
Antonio Humphrey,
UPS Delivery Manager.

[UPS-Package-008536322.zip (application/zip, attachment)]

Send a report that this bug log contains spam.