1

Can the apt-get command be configured to ignore some of the packages it wants to remove. I run both 32 bit and 64 bit development packages as well as the programs created on them, meaning I need both the xxx:i386 and their 64 bit counterparts on the system.In this system for example I need to install a 64bit development package on all the related 32bit development packages are marked for removal.

root@ac02:/usr/src/packages/lazarus# apt-get -f install
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Correcting dependencies... Done
The following packages were automatically installed and are no longer required:
  gir1.2-freedesktop:i386 gir1.2-glib-2.0:i386 gir1.2-pango-1.0:i386 libcairo-gobject2:i386 libcairo-script-interpreter2:i386 libexpat1-dev:i386 libgirepository-1.0-1:i386
  libharfbuzz-gobject0:i386 libharfbuzz-icu0:i386 libice-dev:i386 liblzo2-2:i386 libpcre3-dev:i386 libpcrecpp0:i386 libpng12-dev:i386 libpthread-stubs0-dev:i386 libsm-dev:i386
  libx11-dev:i386 libxau-dev:i386 libxcb-render0-dev:i386 libxcb-shm0-dev:i386 libxcb1-dev:i386 libxcursor-dev:i386 libxdamage-dev:i386 libxdmcp-dev:i386 libxext-dev:i386
  libxfixes-dev:i386 libxinerama-dev:i386 libxrandr-dev:i386 libxrender-dev:i386 zlib1g-dev:i386
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  gir1.2-atk-1.0 gir1.2-gdkpixbuf-2.0 gir1.2-gtk-2.0 libatk1.0-dev libcairo-script-interpreter2 libcairo2-dev libexpat1-dev libfontconfig1-dev libfreetype6-dev libgdk-pixbuf2.0-dev
  libglib2.0-dev libgtk2.0-dev libharfbuzz-dev libharfbuzz-gobject0 libice-dev libpango1.0-dev libpcre3-dev libpcrecpp0 libpixman-1-dev libpng12-dev libpthread-stubs0-dev libsm-dev
  libx11-dev libxau-dev libxcb-render0-dev libxcb-shm0-dev libxcb1-dev libxcomposite-dev libxcursor-dev libxdamage-dev libxdmcp-dev libxext-dev libxfixes-dev libxft-dev libxi-dev
  libxinerama-dev libxrandr-dev libxrender-dev
Suggested packages:
  libcairo2-doc libglib2.0-doc libgtk2.0-doc libice-doc libpango1.0-doc libsm-doc libxcb-doc libxext-doc
The following packages will be REMOVED:
  gir1.2-atk-1.0:i386 gir1.2-gdkpixbuf-2.0:i386 gir1.2-gtk-2.0:i386 libatk1.0-dev:i386 libcairo2-dev:i386 libfontconfig1-dev:i386 libfreetype6-dev:i386 libgdk-pixbuf2.0-dev:i386
  libglib2.0-dev:i386 libgtk2.0-dev:i386 libharfbuzz-dev:i386 libpango1.0-dev:i386 libpixman-1-dev:i386 libxcomposite-dev:i386 libxft-dev:i386 libxi-dev:i386
The following NEW packages will be installed:
  gir1.2-atk-1.0 gir1.2-gdkpixbuf-2.0 gir1.2-gtk-2.0 libatk1.0-dev libcairo-script-interpreter2 libcairo2-dev libexpat1-dev libfontconfig1-dev libfreetype6-dev libgdk-pixbuf2.0-dev
  libglib2.0-dev libgtk2.0-dev libharfbuzz-dev libharfbuzz-gobject0 libice-dev libpango1.0-dev libpcre3-dev libpcrecpp0 libpixman-1-dev libpng12-dev libpthread-stubs0-dev libsm-dev
  libx11-dev libxau-dev libxcb-render0-dev libxcb-shm0-dev libxcb1-dev libxcomposite-dev libxcursor-dev libxdamage-dev libxdmcp-dev libxext-dev libxfixes-dev libxft-dev libxi-dev
  libxinerama-dev libxrandr-dev libxrender-dev
0 upgraded, 38 newly installed, 16 to remove and 33 not upgraded.
1 not fully installed or removed.
Need to get 14.0 MB of archives.
After this operation, 13.4 MB of additional disk space will be used.
Do you want to continue? [Y/n] 

When a package is marked for removal, does that mean that apt-get thinks it conflicts with other packages? This I find rather unexpected as most development systems search for 32bit development packages separately form 64 bit packages.

1
  • Actually this is not about why the conflicts exist, it is more about the existence of an option to the apt-get or dpkg commands which will cause it to skip the removal of possible conflicts if the user thinks there are will be no actual conflicts. As I mentioned I don't think 32bit development packages will interfere with 64bit ones if the linker looks in different directories, unless some linkers are indifferent to that.
    – vfclists
    Mar 5, 2017 at 22:23

1 Answer 1

2

When apt-get decides to remove a package as part of the installation of another package, it's because there's a declared conflict (which might not reflect an actual conflict). Non-multiarch packages conflict with the same package from another architecture; as explained in answer to Why does trying to installing a 64bit library via apt threaten to delete a number of required 32 bit ones? this is often the case with development packages.

You can nevertheless force the installation of a conflicting package, using dpkg --force-conflicts. You'll need to download the affected packages and install them manually, and you won't be able to use apt-get until the conflict is resolved (or rather, apt-get will insist on resolving the conflict). You might break the packages involved in the conflict, but at least you can try...

I'm not aware of an option to disable apt-get's conflict handling.

An alternative is to fix the affected packages; this is simple enough in most cases and will avoid any subsequent issues with apt. For example, for harfbuzz in Debian 8:

  • download the source code and extract it:

    dget http://httpredir.debian.org/debian/pool/main/h/harfbuzz/harfbuzz_0.9.35-2.dsc
    cd harfbuzz-0.9.35
    
  • edit debian/control and add Multi-Arch: same after the Architecture line under Package: libharfbuzz-dev

  • add a changelog entry so that your custom packages won't be replaced by the current version from the archive:

    dch -n "Enable Multi-Arch on the -dev package."
    
  • build the package (you'll need to do this on an amd64 builder and an i386 builder — this is where pbuilder or sbuild come in handy)

    dpkg-buildpackage -us -uc
    

This will produce co-installable libharfbuzz-dev packages. It works because the packages already were co-installable, they just lacked the necessary meta-data. For harfbuzz this has been fixed in Debian 9.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .