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

Bug#37592: dselect automatically deselects libc6 and essential packages



Package: dpkg
Version: 1.4.1.1
Severity: grave

I tried to upgrade my system from slink to potato and found a problem
in dselect. After pressing Enter in [S]elect to leave the select screen,
dselect wants to deselect libc6 and all packages that depend on it (which
is almost any package - including essential ones!).

After some testing I found that the problem is caused by the devscripts
package:

# dpkg -s devscripts
Package: devscripts
[...}
Version: 2.2.4
Depends: dpkg-dev, netstd, patch, perl
Recommends: dupload, libtricks | fakeroot, lintian
Suggests: debian-keyring, pgp, libmd5-perl, perl-suid
Conflicts: debmake (<< 3.5)

As you can see, devscripts recommends "libtricks | fakeroot". libtricks
can't be installed with the new libc6 because ...

# dpkg -s libc6     
Package: libc6
[...]
Version: 2.1.1-3
Replaces: libc6-dev (<< 2.0.110-1), ldso (<< 1.9.10-1.1), timezone, timezones, l
ibdb2, locales (<< 2.1.1-1)
Pre-Depends: ldso (>= 1.8.10-1)
Recommends: gconv-modules, locales
Suggests: nscd, glibc-doc
Conflicts: libc5 (<< 5.4.33-7), libpthread0 (<< 0.7-10), libstdc++2.8 (= 2.90.29
-1), libstdc++2.9 (<< 2.91.59-2), timezone, timezones, libwcsmbs, libc6-doc, lib
tricks, apt (<< 0.3.0)

... libc6 conflicts with it. So the only way to satisfy devscript's
recommendations would be to install fakeroot.

This situation causes the problem: When fakeroot is not installed and
you try to install devscripts, dselect automatically deselects libc6 and
all the other packages (instead of just selecting fakeroot).

I can 100% reproduce this situation: I just have to purge fakeroot and
devscripts, enter dselect and select devscripts again.

No problems occur if you remove libtricks from libc6's conflict line or
from devscript's recommends line in /var/lib/dpkg/status. A possible
workaround would be for devscript to just recommend fakeroot but I think
it's better to solve the real problem.

-- 
Stefan Gybas


Reply to: