tags 632115 confirmed
# technically, this is a regression
severity 632115 important
thanks
On 2011-06-29 19:22, Jakub Wilk wrote:
> Package: lintian
> Version: 2.5.1
> Severity: minor
>
> $ lintian unbound_1.4.10-1_i386.deb unbound_1.4.10-1_amd64.deb
> [...]
> internal error: cannot open unpacked/etc/init.d/unbound: No such file or
> directory
> internal error: cannot run scripts check on package unbound
> warning: skipping check of binary package unbound
>
>
> -- System Information:
> [...]
>
Hey
This looks very reasonable, I have not actually tested, but the code
strongly suggests this being an issue. As I understand it, Lintian has
never really supported this, but until the group processing it "happened
to work".
The problem is that the Lintian Lab only considers type and name of a
package, so two packages with same type and name (regardless of version
and architecture) will be unpacked to the same location.
The issue can appeared after group processing, because the work flow
changed from[2]:
unpack pkg-amd64
check pkg-amd64
auto-clean pkg-amd64
unpack pkg-i386 (replacing pkg-amd64)
check pkg-i386
auto-clean pkg-i386
into:
unpack pkg-amd64
unpack pkg-i386 (replacing pkg-amd64)
check pkg-amd64 (may produce wrong results)
auto-clean pkg-amd64
check pkg-i386 (fails horrible)
auto-clean pkg-i386
(note the ordering of pkg-amd64 vs. pkg-i386 may be wrong here and
there, but it shows the overall picture.)
Obviously, even the old work-flow is problematic, but since most people
only uses a temporary lab and lintian.d.o only checks one architecture
(and we only want one version there), we never really saw this issue.
So to fix this I believe we have to extend the Lab a bit to unpack
$pkg_$version_$arch.$type into $type/$pkg/$version/$arch (or similar)
rather than $type/$pkg (as we do now).
We still have some cross pkg symlinks lying around, personally I would
like to see the removed if possible. With the group processing they
should be redundant.
However, the above fix complicates the lintian.d.o setup, where we (as I
understand it) would like a new version of a package to replace the old one.
I suspect we could solve this by adding attributes to the Lab (at
creation time) that Lintian will respect. This could be something like:
* multi-version: Allow multiple versions of the same pkg in the lab.
- Without this, Lintian will replace the old version when unpacking
a new package of same name. Also pkg_$version1 and pkg_$version2
cannot be processed in the same run.
- With this, any number of versions of a package with the same name
can be present in the Lab. Lintian will not (by default) remove
a pkg_$oldversion when unpacking pkg_$newversion.
* multi-arch: Same as above for architectures rather than versions.
They could default to being on (for new Labs) and we could have the
l.d.o Lab work without multi-version.
~Niels
[1] Determined by name and version of the source package; the packages
in question would be in the same group.
[2] The old work flow is somewhat simplified as some checking is
interleaved with the unpacking.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
