--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: lintian: version-substvar-for-external-package raised for dbgsym packages from same source
- From: Luca Boccassi <luca.boccassi@gmail.com>
- Date: Wed, 5 Apr 2017 17:15:20 +0100
- Message-id: <CAMw=ZnSs-Q720Aom_OX0e=Lbkxjy4TiwDLogiHczkP2g3YNZqQ@mail.gmail.com>
Package: lintian
Version: 2.5.50.1
Severity: normal
Dear Maintainer,
TL;DR: Lintian reports the version-substvar-for-external-package error when the
"external package" in question is actually a dbgsym package generated by the
same source package.
I maintain a source package, dpdk [1], which builds a great many libraries.
Consequently, in stretch, a lot of dbgsym packages are generated.
As a shortcut, a colleague wanted to add an empty metapackage, libdpdk-dbgsym,
which depends on all the generated -dbgsym packages. Unfortunately Lintian
raises the (unoverridable) error mentioned above due to a line similar to this:
Package: libfoo
...
Package: libbar
...
Package: foobar-dbg-meta
Depends: libfoo-dbgsym (= ${binary:Version}), libbar-dbgsym (=
${binary:Version})
Given all the dbgsym packages have predictable names, and are created from
packages listed in debian/control (ie: libfoo will be in d/control), could
Lintian perhaps recognize this and avoid raising this error?
Thank you!
Kind regards,
Luca Boccassi
[1] https://tracker.debian.org/pkg/dpdk
-- System Information:
Debian Release: 9.0
APT prefers testing-proposed-updates
APT policy: (500, 'testing-proposed-updates'), (500,
'testing-debug'), (500, 'testing'), (103, 'unstable'), (102,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages lintian depends on:
ii binutils 2.28-2
ii bzip2 1.0.6-8.1
ii diffstat 1.61-1+b1
ii file 1:5.29-3
ii gettext 0.19.8.1-2
ii intltool-debian 0.35.0+20060710.4
ii libapt-pkg-perl 0.1.32
ii libarchive-zip-perl 1.59-1
ii libclass-accessor-perl 0.34-1
ii libclone-perl 0.38-2+b1
ii libdpkg-perl 1.18.23
ii libemail-valid-perl 1.202-1
ii libfile-basedir-perl 0.07-1
ii libipc-run-perl 0.94-1
ii liblist-moreutils-perl 0.416-1+b1
ii libparse-debianchangelog-perl 1.2.0-12
ii libperl5.24 [libdigest-sha-perl] 5.24.1-2
ii libtext-levenshtein-perl 0.13-1
ii libtimedate-perl 2.3000-2
ii liburi-perl 1.71-1
ii libyaml-libyaml-perl 0.63-2
ii man-db 2.7.6.1-2
ii patchutils 0.3.4-2
ii perl 5.24.1-2
ii t1utils 1.39-2
ii xz-utils 5.2.2-1.2+b1
Versions of packages lintian recommends:
ii dpkg 1.18.23
ii libperlio-gzip-perl 0.19-1+b2
ii perl 5.24.1-2
ii perl-modules-5.24 [libautodie-perl] 5.24.1-2
Versions of packages lintian suggests:
ii binutils-multiarch 2.28-2
ii dpkg-dev 1.18.23
ii libhtml-parser-perl 3.72-3
ii libtext-template-perl 1.46-1
-- no debconf information
--- End Message ---
--- Begin Message ---
- To: 859659-done@bugs.debian.org
- Cc: Luca Boccassi <luca.boccassi@gmail.com>
- Subject: Re: lintian: version-substvar-for-external-package raised for dbgsym packages from same source
- From: Chris Lamb <lamby@debian.org>
- Date: Fri, 12 Jan 2018 10:38:11 +0530
- Message-id: <1515733691.1515904.1232771064.4EEF0C82@webmail.messagingengine.com>
tags 859659 + wontfix
thanks
Luca Boccassi wrote:
> In our specific case at work, as you correctly guessed, we don't have a
> separate archive (build and repository management system is Suse's OBS)
> so it does work. Of course being an external use case from Debian I
> can't ask for it to be supported, so please feel free to close the bug
> if you wish.
Will do - many thanks :)
Best wishes,
--
,''`.
: :' : Chris Lamb
`. `'` lamby@debian.org / chris-lamb.co.uk
`-
--- End Message ---