Joey Hess wrote:
Package: pciutils
Version: 1:2.1.11-10
Severity: critical
This version of pciutils depends on two new packages, libpci2 and
libpci1. pciutils is part of the base system, and these packages are
not, and thus it broke the base system dependency freeze announced by the
release managers[1].
* As of now, no new packages will be added to the base system. This
means that packages in the base system *must not* change their
package relationships.
If this package enters sarge, it will break various d-i beta3 installation
media (floppies, netboot, businesscard cdroms, etc), and it will further
delay the release of sarge.
We can perhaps revisit this after beta4 of d-i is released.
OK, let's get this fixed ASAP.
I propose to build a new pciutils package, without a separate libpci2
package but just libpci.so.2 included as a shared lib. It will not
depend on libpci1.
The libpci.so.2 (different ABI as .so.1) is required because otherwise
the package does not work on sparc running a 2.6 kernel.
Some other packages (around 10-15, IIRC), not in the base system, rely
on libpci.so.1, and/or the 'old' output of 'lspci' (without some prefix
0's). I will not ship libpci.so.1. Neither as part of a new pciutils
package, nor in a separate package. Instead, I will check and if
necessary file RC bugs against these packages.
Is this acceptable?
Basically, it moves the problem from debootstrap (or base system) to
some other packages, but given the freeze on the base system I do not
see any other good solutions.
Two alternatives, that I dislike but anyway, are 1) to ship libpci.so.1
next to libpci.so.2 in the pciutils package (still some other packages
have problems because of the changed 'lspci' output, or 2) to ship
libpci.so.1 in a libpci1 package, but the same problem remains.
Also, I will fix the warning the 'lspci' currently gives when running on
2.4 systems (without sysfs support).
Thank you,
Remco
PS Please include me in the CC list when replying.
