Bug#758425: lintian: add a check for outdated version constraints
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/20140829095214.gv19...@stoneboat.aleph1.co.uk 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/ -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140829191606.ga11...@x230-buxy.home.ouaza.com
Bug#758425: lintian: add a check for outdated version constraints
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/20140829095214.gv19...@stoneboat.aleph1.co.uk 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 -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140829193245.3685.24196@hoothoot
Bug#758425: lintian: add a check for outdated version constraints
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/ -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140829201743.gc19...@x230-buxy.home.ouaza.com
Bug#758425: lintian: add a check for outdated version constraints
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 -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140829202304.3685.28963@hoothoot
Bug#758425: lintian: add a check for outdated version constraints
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/ -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140829214242.ge19...@x230-buxy.home.ouaza.com
Bug#758425: lintian: add a check for outdated version constraints
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 -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140830045715.3685.92020@hoothoot
