Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

stretch-backports - how to enable automatically? [SOLVED]

Ask for help with issues regarding the Installations of the Debian O/S.
Message
Author
Dai_trying
Posts: 1100
Joined: 2016-01-07 12:25
Has thanked: 5 times
Been thanked: 16 times

Re: stretch-backports - how to enable automatically? [SOLVED

#21 Post by Dai_trying »

lefsha wrote:another broken dependency:

Code: Select all

apt -t stretch-backports install zfs-dkms zfs-initramfs
resulting in:

Code: Select all

/var/lib/dkms/zfs/0.7.9/build/configure: line 13069: dpkg-architecture: command not found
I just tried that command in a VM of Stretch Xfce fresh installation with just the backports repo added and it worked perfectly fine without error (just a license warning).

But then again I ran the nvidia driver command too and that installed without issue...

Maybe you have altered your system somehow that is causing this effect.

EDIT: Apologies I was looking in the wrong VM, the one running this had screen-saved and was paused at the error you mentioned... although "make" seems to still be running.

lefsha
Posts: 15
Joined: 2018-06-16 11:05

Re: stretch-backports - how to enable automatically?

#22 Post by lefsha »

Head_on_a_Stick wrote:But you are not using the Debian stable main repositories alone, you have added backports, most backports will be installable but sometimes there will be transitions in testing/unstable that will make certain packages temporarily uninstallable.
I am tired to repeat again and again - nothing besides stable has been installed! The very first attempt to install nvidia-driver failed. Failed means it wasn't installed!
How one can damage the system by changing config files? I am not that stupid to believe it is possible.
Head_on_a_Stick wrote:[*]Why is `apt -s install` not good enough?[/*]
Every one who have seen the output of "emerge -at" will miss it everywhere.

apt -s is separate command. I can't confirm and install it.
I have to call apt twice and the output is messy! Look here:

Code: Select all

apt -s install nginx
Output:

Code: Select all

Reading state information... Done
The following additional packages will be installed:
  libgeoip1 libnginx-mod-http-auth-pam libnginx-mod-http-dav-ext libnginx-mod-http-echo libnginx-mod-http-geoip libnginx-mod-http-image-filter libnginx-mod-http-subs-filter
  libnginx-mod-http-upstream-fair libnginx-mod-http-xslt-filter libnginx-mod-mail libnginx-mod-stream nginx-common nginx-full
Suggested packages:
  geoip-bin fcgiwrap nginx-doc
Recommended packages:
  geoip-database
The following NEW packages will be installed:
  libgeoip1 libnginx-mod-http-auth-pam libnginx-mod-http-dav-ext libnginx-mod-http-echo libnginx-mod-http-geoip libnginx-mod-http-image-filter libnginx-mod-http-subs-filter
  libnginx-mod-http-upstream-fair libnginx-mod-http-xslt-filter libnginx-mod-mail libnginx-mod-stream nginx nginx-common nginx-full
0 upgraded, 14 newly installed, 0 to remove and 0 not upgraded.
Inst libgeoip1 (1.6.9-4 Debian:9.4/stable [amd64])
Inst nginx-common (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [all])
Inst libnginx-mod-http-auth-pam (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Inst libnginx-mod-http-dav-ext (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Inst libnginx-mod-http-echo (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Inst libnginx-mod-http-geoip (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Inst libnginx-mod-http-image-filter (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Inst libnginx-mod-http-subs-filter (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Inst libnginx-mod-http-upstream-fair (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Inst libnginx-mod-http-xslt-filter (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Inst libnginx-mod-mail (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Inst libnginx-mod-stream (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Inst nginx-full (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Inst nginx (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [all])
Conf libgeoip1 (1.6.9-4 Debian:9.4/stable [amd64])
Conf nginx-common (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [all])
Conf libnginx-mod-http-auth-pam (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Conf libnginx-mod-http-dav-ext (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Conf libnginx-mod-http-echo (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Conf libnginx-mod-http-geoip (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Conf libnginx-mod-http-image-filter (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Conf libnginx-mod-http-subs-filter (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Conf libnginx-mod-http-upstream-fair (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Conf libnginx-mod-http-xslt-filter (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Conf libnginx-mod-mail (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Conf libnginx-mod-stream (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Conf nginx-full (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [amd64])
Conf nginx (1.10.3-1+deb9u1 Debian:9.4/stable, Debian-Security:9/stable [all])
It does repeat dependency 4!!! times. Four times, Carl! (c) Twice without version, then 2 times with version. It's just too much blah-blah-blah.
It's not a tree to graphically see what depends on what. There is no way to reinstall the whole dependency tree.
It's actually useless. Then I have to type it again to perform the actual install.

Try it with task-mate-desktop or another huge tree metapackage and you won't look at it.
Besides there are no properly made metapackages in Debian.

Now try it after you have it installed:

Code: Select all

Reading package lists... Done
Building dependency tree       
Reading state information... Done
task-mate-desktop is already the newest version (3.39).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Wow. 5 lines for zero info is way too much for my taste.
Why not just print the whole tree, mark it green and make user happy?
Head_on_a_Stick wrote: Pin the repository to 500, then it will match the stable repository pin value and APT will prefer the newest package version available.
Nope. It doesn't work that way. I was trying it at the first line. It does break everything before installation. It does something totally wrong.
It is not an option at all for any kind of purpose. Which is just confirm my opinion about broken dependency structure at Debian.
Head_on_a_Stick wrote: The problem occurs because the complete dependency chain may not be available in backports at any given time, the packages and associated dependencies in the non-stable repositories are in a constant state of flux.
Well that is easily achievable with any repo including the stable one! Look at my previous message. Sometimes some dependencies are missing even at stable.
If you have the whole system installed you won't recognize it, because many packages installed anyway. On a fresh system I see it quite often. It's not distro
specific.
Head_on _a_Stick wrote:And how do you know if any depencies have already been pulled in from that repository and polluted your chain?
OMG. I cannot repeat myself 4 times. I am not "apt -s" from Debian!
But OK. Follow my fingers:

1st step:

Code: Select all

debootstrap stretch /mnt/linux
2nd step:

Code: Select all

deb http://deb.debian.org/debian stretch main contrib non-free
deb http://deb.debian.org/debian stretch-updates main contrib non-free
deb http://security.debian.org/debian-security/ stretch/updates main contrib non-free
deb http://deb.debian.org/debian stretch-backports main contrib non-free
deb http://deb.debian.org/debian stretch-proposed-updates main contrib non-free
3rd step:

Code: Select all

deb http://deb.debian.org/debian stretch main contrib non-free
deb http://deb.debian.org/debian stretch-updates main contrib non-free
deb http://security.debian.org/debian-security/ stretch/updates main contrib non-free
deb http://deb.debian.org/debian stretch-backports main contrib non-free
#deb http://deb.debian.org/debian stretch-proposed-updates main contrib non-free
Got the trick? :D
Head_on _a_Stick wrote: Also, did you `apt update` after removing the line?
Let me not answer that question. It sound way too silly. If not happy look at 3 steps above...
Head_on _a_Stick wrote:Did you actually try `aptitude` instead of `apt`, as suggested several times?
Yes I did. No difference besides too much output and boost dependency telling me the authors aren't quite sane.

Boost lib is quite a nice marker to separate a well written software from software written by newbies
influenced by some hypes. So nope. There are no place for it at my system.
Head_on _a_Stick wrote:The superior dependency resolution algorithms of that program may have offered the desired solution.
If the original concept of dependencies is broken by design no smart software is able to solve it.
And there is no human on earth who will be able to convince me into the opposite.

I do prefer the suckless concept. Unfortunately it doesn't have much support from community. There is a general misunderstanding
coming from early ages, when RAM was too small, too expensive. It's a show stopper for future development, but the off-topic here.
Last edited by lefsha on 2018-06-16 19:42, edited 1 time in total.

User avatar
bw123
Posts: 4015
Joined: 2011-05-09 06:02
Has thanked: 1 time
Been thanked: 28 times

Re: stretch-backports - how to enable automatically? [SOLVED

#23 Post by bw123 »

Dai_trying wrote:
lefsha wrote:another broken dependency:

Code: Select all

apt -t stretch-backports install zfs-dkms zfs-initramfs
resulting in:

Code: Select all

/var/lib/dkms/zfs/0.7.9/build/configure: line 13069: dpkg-architecture: command not found
I just tried that command in a VM of Stretch Xfce fresh installation with just the backports repo added and it worked perfectly fine without error (just a license warning).

But then again I ran the nvidia driver command too and that installed without issue...

Maybe you have altered your system somehow that is causing this effect.

EDIT: Apologies I was looking in the wrong VM, the one running this had screen-saved and was paused at the error you mentioned... although "make" seems to still be running.
Looking up the error msg on the internets led to this:
https://forum.openmediavault.org/index. ... ?pageNo=37

39 page thread, says the error still results in a working zfs. Adding dpkg-dev as a dependency would not solve the error apparently.
resigned by AI ChatGPT

lefsha
Posts: 15
Joined: 2018-06-16 11:05

Re: stretch-backports - how to enable automatically? [SOLVED

#24 Post by lefsha »

bw123 wrote:39 page thread, says the error still results in a working zfs. Adding dpkg-dev as a dependency would not solve the error apparently.
Frankly, I am not able to look through the all dependencies which are really required and which aren't (time issue). Otherwise I would be better suited to come with my own distro
or LFS at least. I am very well aware, that some dependencies aren't really required despite error or warning messages. For user level packages I do voluntary
forbid to debian install dependencies, because I know Debian is wrong. On the system level I do prefer Debian takes responsibility, because I don't wish to
end up with not booting system.
For example I hate grub and try to avoid using it as much as I can, but I failed to find a way to use syslinux/extlinux with ZFS. Now I have to use it, because
ZFS has higher priority for me. Well life isn't perfect and we have to take compromises.

P.S. That is why I do prefer to split the system from user level.
P.P.S In fact installation of dpkg-dev does solve the problem of warning message at least.

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: stretch-backports - how to enable automatically?

#25 Post by Head_on_a_Stick »

lefsha wrote:
Head_on _a_Stick wrote:Did you actually try `aptitude` instead of `apt`, as suggested several times?
Yes I did. No difference besides too much output
Did you not read the questions asked by `aptitude` then?

I have just simulated the successful installation of the nvidia-driver package on my own Debian stretch system (which has backports enabled and functional, btw).

I will allow that the original command failed:

Code: Select all

empty@hegel:~ $ apt install -s nvidia-driver
NOTE: This is only a simulation!
      apt needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 nvidia-driver : Depends: nvidia-driver-libs (= 375.82-1~deb9u1) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
100|empty@hegel:~ $
So let's investigate why:

Code: Select all

empty@hegel:~ $ aptitude why-not nvidia-driver-libs
Not currently installed
The candidate version 375.82-1~deb9u1 has priority optional
No dependencies require to remove nvidia-driver-libs
1|empty@hegel:~ $
Hmmm, OK, so you do need to specify it in the command line.

Or let `aptitude` suggest this for you:

Code: Select all

empty@hegel:~ $ aptitude install -s nvidia-driver                            
The following NEW packages will be installed:
  dkms{a} glx-alternative-mesa{a} glx-alternative-nvidia{a} 
  glx-diversions{a} libegl-nvidia0{a} libegl1-glvnd-nvidia{a} 
  libgl1-glvnd-nvidia-glx{a} libgl1-nvidia-glvnd-glx{a} 
  libgldispatch0-nvidia{ab} libgles-nvidia1{a} libgles-nvidia2{a} 
  libgles1-glvnd-nvidia{a} libgles2-glvnd-nvidia{a} libglvnd0{ab} 
  libglvnd0-nvidia{ab} libglx-mesa0{ab} libglx-nvidia0{a} libglx0{ab} 
  libjansson4{a} libnvidia-cfg1{a} libnvidia-eglcore{a} libnvidia-glcore{a}
  libnvidia-ml1{a} libopengl0-glvnd-nvidia{a} libxnvctrl0{a} 
  linux-compiler-gcc-6-x86{a} linux-headers-4.9.0-6-amd64{a} 
  linux-headers-4.9.0-6-common{a} linux-headers-amd64{a} 
  linux-kbuild-4.9{a} nvidia-alternative{a} nvidia-driver 
  nvidia-driver-bin{a} nvidia-driver-libs{a} nvidia-egl-common{a} 
  nvidia-egl-icd{a} nvidia-installer-cleanup{a} nvidia-kernel-common{a} 
  nvidia-kernel-dkms{a} nvidia-kernel-support{a} nvidia-legacy-check{a} 
  nvidia-modprobe{a} nvidia-persistenced{a} nvidia-settings{a} 
  nvidia-support{a} nvidia-vdpau-driver{a} nvidia-vulkan-common{a} 
  nvidia-vulkan-icd{a} update-glx{a} xserver-xorg-video-nvidia{a} 
0 packages upgraded, 50 newly installed, 0 to remove and 0 not upgraded.
Need to get 39.9 MB of archives. After unpacking 175 MB will be used.
The following packages have unmet dependencies:
 libgldispatch0-nvidia : Conflicts: libglvnd0 but 1.0.0+git20180308-2~bpo9+1 is to be installed
 libglx-mesa0 : Depends: libdrm2 (>= 2.4.75) but 2.4.74-1 is installed
                Depends: libglapi-mesa (= 17.3.9-1~bpo9+1) but 13.0.6-1+b2 is installed
 libglvnd0 : Breaks: libgldispatch0-nvidia but 375.82-1~deb9u1 is to be installed
The following actions will resolve these dependencies:

     Install the following packages:                      
1)     libglx0-glvnd-nvidia [375.82-1~deb9u1 (stable)

     Keep the following packages at their current version:
2)     libglvnd0 [Not Installed]                          
3)     libglvnd0-nvidia [Not Installed]                   
4)     libglx-mesa0 [Not Installed]                       
5)     libglx0 [Not Installed]                            



Accept this solution?  [Y/n/q/?] y
The following NEW packages will be installed:
  dkms{a} glx-alternative-mesa{a} glx-alternative-nvidia{a} 
  glx-diversions{a} libegl-nvidia0{a} libegl1-glvnd-nvidia{a} 
  libgl1-glvnd-nvidia-glx{a} libgl1-nvidia-glvnd-glx{a} 
  libgldispatch0-nvidia{a} libgles-nvidia1{a} libgles-nvidia2{a} 
  libgles1-glvnd-nvidia{a} libgles2-glvnd-nvidia{a} libglx-nvidia0{a} 
  libglx0-glvnd-nvidia{a} libjansson4{a} libnvidia-cfg1{a} 
  libnvidia-eglcore{a} libnvidia-glcore{a} libnvidia-ml1{a} 
  libopengl0-glvnd-nvidia{a} libxnvctrl0{a} linux-compiler-gcc-6-x86{a} 
  linux-headers-4.9.0-6-amd64{a} linux-headers-4.9.0-6-common{a} 
  linux-headers-amd64{a} linux-kbuild-4.9{a} nvidia-alternative{a} 
  nvidia-driver nvidia-driver-bin{a} nvidia-driver-libs{a} 
  nvidia-egl-common{a} nvidia-egl-icd{a} nvidia-installer-cleanup{a} 
  nvidia-kernel-common{a} nvidia-kernel-dkms{a} nvidia-kernel-support{a} 
  nvidia-legacy-check{a} nvidia-modprobe{a} nvidia-persistenced{a} 
  nvidia-settings{a} nvidia-support{a} nvidia-vdpau-driver{a} 
  nvidia-vulkan-common{a} nvidia-vulkan-icd{a} update-glx{a} 
  xserver-xorg-video-nvidia{a} 
0 packages upgraded, 47 newly installed, 0 to remove and 0 not upgraded.
Need to get 39.6 MB of archives. After unpacking 173 MB will be used.

Note: Using 'Simulate' mode.
Do you want to continue? [Y/n/?] 
Would download/install/remove packages.
empty@hegel:~ $
All done! :)

As I said, the nvidia-driver package isn't part of the official release so maybe a little hacking around is to be expected.
deadbang

lefsha
Posts: 15
Joined: 2018-06-16 11:05

Re: stretch-backports - how to enable automatically? [SOLVED

#26 Post by lefsha »

Sorry to everyone! Actually the issue wasn't solved. The dependency tree is broken and anyone who will try to install it
should not try it. Developers would be better suited if thinking in the terms of dependency tree and not single packages.
Absent package is always better, than broken dependency. Very sad.

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: stretch-backports - how to enable automatically? [SOLVED

#27 Post by Head_on_a_Stick »

lefsha wrote:The dependency tree is broken
Only for you: did you not read my last post?

Running debootstrap(8) and adding some repositories does not a complete Debian system make...

https://www.debian.org/releases/stable/ ... 03.html.en
deadbang

User avatar
bw123
Posts: 4015
Joined: 2011-05-09 06:02
Has thanked: 1 time
Been thanked: 28 times

Re: stretch-backports - how to enable automatically?

#28 Post by bw123 »

lefsha wrote:
Dai_trying wrote:I have been using backports on both Jessie and Stretch installations without issue here, it has always pulled in the appropriate dependent packages.Do you have other repositories added?
apt policy should tell you which are enabled but you probably know that already as you are more experienced.
Also does apt update give any errors that might give a hint?
Brand new install in chroot! Nothing besides base. Trying again. The same issue. Just added:

Code: Select all

deb http://deb.debian.org/debian stretch main contrib non-free
deb http://deb.debian.org/debian stretch-updates main contrib non-free
deb http://security.debian.org/debian-security/ stretch/updates main contrib non-free
deb http://deb.debian.org/debian stretch-backports main contrib non-free
deb http://deb.debian.org/debian stretch-proposed-updates main contrib non-free
This is the repo I use, per instructions here https://backports.debian.org/Instructions/
#deb http://ftp.debian.org/debian stretch-backports main contrib non-free

I do use the deb.debian redirector for main, but I have never tried it for backports? Did you find documentation for it with backports?
resigned by AI ChatGPT

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: stretch-backports - how to enable automatically?

#29 Post by Head_on_a_Stick »

bw123 wrote:I do use the deb.debian redirector for main, but I have never tried it for backports?
Works on my box:

Code: Select all

empty@hegel:~ $ grep backport /etc/apt/sources.list                    
deb https://cdn-aws.deb.debian.org/debian/ stretch-backports main
empty@hegel:~ $ apt policy mksh                                        
mksh:
  Installed: 56c-1~bpo9+1
  Candidate: 56c-1~bpo9+1
  Version table:
 *** 56c-1~bpo9+1 100
        100 https://cdn-aws.deb.debian.org/debian stretch-backports/main amd64 Packages
        100 /var/lib/dpkg/status
     54-2+b4 500
        500 https://cdn-aws.deb.debian.org/debian stretch/main amd64 Packages
empty@hegel:~ $
The apt-transport-https package is needed for https sources though.
deadbang

lefsha
Posts: 15
Joined: 2018-06-16 11:05

Re: stretch-backports - how to enable automatically? [SOLVED

#30 Post by lefsha »

Head_on_a_Stick wrote: Only for you: did you not read my last post?
Yes. I did. Thank you very much! I do really appreciate the help
from this community! It is possibly my fault and I don't blame anyone.

Frankly, in general I did recognize my opinion is usually some how
different then that from the others. I did try Debian many times over
years, but it wasn't made for me.

Last days I set up another distro (*) from scratch and everything seems to be working.
It sounds like the maintenance of that particular distro is easier for me, although
it is less preconfigured by default and requires a lot of manual treatment.

There is a dependency issue as well (not the one like with Debian though),
but it's impossible to avoid it completely in a binary based distro.
Most of developers tend to include commonly used components even there aren't
necessary to satisfy an average user.

Personally I would prefer static linking for everything and using plug-in design
for optional components or client-server model for other things.
I find personally dynamic linking is an evil, cause deletion of a single file
can brake the whole system which is kind of insane behavior to me.
Versioning issue is another problem of dynamic linking. That one I faced with Debian.
I do agree that management of different versions of libs is far from being a trivial task.
Hopefully 10+ years later on when RAM per GB will be cheap enough and people will
get rid of it completely. But to change the people mentality is far more difficult task,
than to make RAM cheaper. I read articles claiming dynamic linking is a good
thing, but I can't find them reasonable. This thread is a confirmation for it. Without
dynamic linking there won't be such a thread and many many others too.
And there will be no Docker too...

Thank you all again. And sorry for being not flexible enough.
(*) - I didn't name the Distro I moved in to avoid the flame.

kistvan74
Posts: 1
Joined: 2019-03-12 14:20

Re: stretch-backports - how to enable automatically? [SOLVED

#31 Post by kistvan74 »

I totally feel the pain of this guy!! Some answers were given, but as someone who is dealing with the same problems, I feel they are inadequate. To help anyone with similar issues, even though it is marked as solved, I would like to add some extra pointers, not mentioned here.

How to get Debian to do what you want, without breaking it?


He had 2 main issues:


1) no usable dependency tree can be printed

The answer was: "yeah, there is none, deal with it"

So what can be done?

already mentioned:
aptitude why <package>
aptitude why-not <package>

# 1-liner, shortened (omitted elements in the chain):
aptitude -v --show-summary=all-packages why <package>

# what depends on this package:
aptitude search '~i~D<package>'

# what would happen, if <package> is removed:
# -s : simulate mode
aptitude -s purge <package>

# the packages that are immediately dependent on this one:
apt-cache rdepends <package>
# build a recursive dependency tree, no pretty-formatting, no indication of installed/manual/auto/etc.
apt-cache rdepends --recurse <package>

# reverse dependency chain:
apt install apt-rdepends
# NOTE: it seems to be broken (did not generate any output for me)
#apt-rdepends -r <package> | less

# what depends on this
apt-cache depends <package>
# build a recursive dependency tree, no pretty-formatting, no indication of installed/manual/auto/etc.
apt-cache depends --recurse <package>


2) metapackages make uninstalling parts of the system impossible

So, you made the mistake of selecting metapackages - which was the easy choice at _install_ time -, now you want to upgrade a single package, but it has some weird dependency of some obscure component you have never used, but if you remove it, the whole gnome will go down with it! Bummer.

So, what can you do?

"gnome" is a metapackage, which pulls in stuff you need, and stuff you don't need, but other people may.

Why everything goes hellish, when you try to remove "gnome"?

The answer is the installed packages have a qualifier "manual" or "auto". To the package manager, manual means "this guy went the extra mile to manually type in the command to install this package, pretty sure s/he needs it badly, we should not touch it! - unless maybe if it is an apt dist-upgrade".

First, how to see what is installed manually?

apt-mark showmanual | sort
aptitude search '~i !~M' -F '%p' | sort
NOTE: Many of these obscure aptitude commands I pulled from answers on the net, without understanding them, their output seems ok, but I would not know, if they are broken after an upgrade. So I tend to use the apt stuff, at least I can easily look those args up in the manual.

Second, how to discard the "manual" flag?
apt-mark auto <package>

What do you do with this?
a) get the offending metapackage
b) mark it as "auto"
c) remove it - well, not. If you remove it now, all the packages installed because of it will be removed, as well! (or at least they will be vulnerable to "apt autoremove")
d) use "apt depends <metapackage>" or "apt(-cache) show <metapackage>" to find the packages that are immediately dependent on the metapackage, and mark them "manual":
apt install <dependent-package1> <dependent-package2> ...

-- there are likely more metapackages down the road, until you isolate the problem-branch enough, not to break stuff you use, so these steps are recursive, but they will get the job done of pinpointing the branch you don't need anymore, while leaving you with the stuff you actually want to use.

Alternatively, you can
aptitude install <package>

and keep typing "n<ENTER>" until a good solution turns up. The problem is, aptitude honors "manual" more than "auto", so with a package like "gnome", you will stuck with hundreds of weird options, and the outputs overflow the screen...

NOTE: There is a shiny new "apt" interface (no "-get" or "-cache" suffix), however, sometimes it sucks. They tried to make it more human readable, but it became less scriptable. The cases I encounter daily:
apt search <package>
-> every 3rd line of the output is an empty line
-> the package description is on a separate line
=> cannot use "apt search <some_generic_term_I_vaguely_remember_from_the_package_name> | grep <some_other_keyword_I_hope_is_in_the_description>"
solution: just use
apt-cache search <clue1> | grep <clue2> | less # then /clue1<ENTER> to highlight "clue1" for readability

e.g. ncurses-something-python, or python-something-ncurses, or python-something with a mention of curses?
apt-cache search python | grep curses | less # /curses<ENTER>

apt show <package>
-> this will output info on every single version available for this package, you may want exactly this
=> the problem is, you don't know which of these are installed / would be installed... sometimes it will overflow your screen... so you have to use the mouse, and another window with more commands to find the part of the output you are interested in, and actually see it on screen...
"just print that package info that is installed/would be installed":
apt-cache show <package>


APPENDIX 1)

You just need that software to be able to work, you don't care about the whole packaging / versioning, you know it won't harm your system, and you don't want to spend days getting the dependencies straight. Also, you don't want to install stuff out of the packaging system, because you want to be able to remove stuff cleanly. What to do?

apt install checkinstall

a) download source
b) check homepage / source README/BUILD guide for dependencies
c) ./configure && make
d) checkinstall -> this will call "make install" in a separated environment, create a .deb package AND install that package right away (as in "dpkg -i <package>)

A local repo for this stuff may be in order, so 3 weeks later you still have a clue, where this package came from, why is it there, etc.:
cat /etc/apt/sources.list <<END

### LOCAL ###

# local packages
# does not have a "Release" file, recent debian won't touch it
deb [trusted=yes] file:/usr/local/debs/ DEBS/
END

mkdir -p /usr/local/debs/DEBS
cp <package> /usr/local/debs/DEBS
cd /usr/local/debs
dpkg-scanpackages DEBS | gzip -9c > DEBS/Packages.gz
apt update

NOTE: I have never looked into it, if checkinstall detects conflicts. Like files overwriting each other in /usr/share, or something like that.


APPENDIX 2)

For stuff like nvidia-drivers: where the package branch is kinda separated, and also you just kinda want to see if it works at all, but you don't want to run "NVIDIA-....run" directly because you don't exactly trust them that they nailed the uninstalling, in case something goes wrong. While I am at the point of trying that, I did not quite finish with trying this method, you can try creating a custom package by gutting out the stable package you already have, and put the new content in there. This will cheat the dpkg system to believe everything is perfect version-wise, and you have the option to seriously mess up your system, or succeed where no path was shown before.

Here is how you create a backport:
https://wiki.debian.org/SimpleBackportCreation

On the downside, for a package-branch like nvidia's non-free, you may have to backport a bunch of packages...

Again, I am just researching this method now, so I don't know, in exactly which cases it may be helpful.

You used chroot, which is nice. When experimenting on your base system (because you don't mind reinstalling from scratch), you may want to do this:
First you should do a backup of your system. This is not a safe restore point, you need it to confirm that your system is indeed in a safe state after uninstalling the wreckages of the latest failed attempt - in case you don't want to reinstall everything right away, just in case. So don't do a compressed backup, do a backup you can easily "diff -rq / /path/to/backup" later.


APPENDIX 3)

apt-pinning: Don't do that. I said DON'T DO THAT!!! I had a few tries with it, had it for a long time, it is destined to end with an unupgradable system. Unupgradeable as in:
- obscure errors about "held" packages, "broken" packages, but you find none on your system...
- you want to return to stable, but it just does not work...
- you want to move up to sid, but it does not work, either
- there is a new stable version, but apt dist-upgrade fails
- aptitude cannot seem to solve the problem without uninstalling every single package you have
- you manually try to fix stuff, forcefully delete packages, cry in a corner
- until you realize doing a clean install is actually pretty quick (hope you have some notes on the packages you installed and loved, along with instructions how to configure everything to your taste...)
=> because of this, use the methods I mentioned previously, since those are more likely to do localized damage to your system, if any, while apt-pinning will nuke it into a tangled mess.

# a few methods to search for held packages:
dpkg --audit
dpkg --get-selections | grep hold
aptitude search "~ahold"

# find installed packages that have issues (like broken - "b", "rc" means it is apt remove-ed, but the config files are still there, use apt purge to get rid of those):
dpkg -l | grep -v '^ii'

# find orphaned packages, which are auto installed, but nothing depends on them anymore (useful after a dpkg --purge <package>)
deborphan
debsums
aptitude search ~b
# check for deviations from the original package contents
debsums_init
debsums -c
apt-get install reinstall <changed packages>

Post Reply