[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#225521: Bug#244583: broke base dependency freeze; cannot enter testing



Hi,

Apologies for following up on myself, but I'd like to have some input from you :-) See below.

Remco van de Meent wrote:
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).


I have implemented the changes as mentioned above, and put the resulting pciutils 1:2.1.11-10.999 package on http://people.debian.org/~remco/

This version removes (replaces, conflicts) libpci2, and does not mention libpci1. It also does not warn for missing /sys on <2.6 kernels.

If you agree with this approach, I'll upload this as version 1:2.1.11-11, ask ftpadmin to remove the libpci1 package from unstable, and file bugs against the packages that (I find to) break due to these changes to pciutils.

Awaiting comments,

Thanks,
Remco



Reply to: