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
lefsha
Posts: 15
Joined: 2018-06-16 11:05

Re: stretch-backports - how to enable automatically?

#16 Post by lefsha »

Head_on_a_Stick wrote:So the GPL means nothing to you then? (Just curious)
Tell me of FS of the same quality like ZFS and I will follow. BTRFS is broken by design. My data are more valuable to me, than everything else.
Is it not the same for others? (Just curious)
Actually I started with FreeBSD, those guys say the same about freedom... They think GPL is bad and switched to clang. I leave the fight for others.
My opinion - it is stupid to be religious about practical things. What really matters is it works or it doesn't. Everything else is just blah-blah-blah.
Head_on_a_Stick wrote: Not true: you could add stable, testing or even experimental repsoitories to your sid system and pin older versions from there ;)
Too much work. Too high risk to fail. Actually I was fine with sid only. Few user relevant packages were broken. System relevant things were fully OK.
I was not able to downgrade certain packages and therefore have to start dancing with repos. Frankly FBSD is quite reasonable to split system from apps.
It's just too old from design point of view, driver support and crazy of licenses.
Head_on_a_Stick wrote: Please read apt_preferences(5) before attempting this though — as you have already discovered, unskilled use of the pinning system can very easily b0rk a system :D
First I haven't installed ANY single package while pinning backports. I was trying this and that to succeed. No change has been made to the system. After discovering, that pinning doesn't help
I switched that off. So if base is broken by default, then yes it is broken, otherwise it is not. In other words it is broken as much as "debootstrap stretch /mnt/linux" can be broken.
Head_on_a_Stick wrote:Yes, it is amongst the most powerful and capable of all the package management systems but this does make it more difficult to understand and use correctly — I too came from Arch and it took me a while to "up-skill" to Debian, in fact the process still continues :)
Frankly the most powerful under Linux Umbrella is Gentoo. No one can compete with that. While doing a simple "apt install package" I am always missing:
1. Dependency tree, which I can get with emerge -t
2. Versions of packages going to be installed, which I can get with emerge -a
3. There is no way to list installing package if it is the only one before installation to confirm it or prevent it - emerge -a
In many cases I wish to see what will happen if doing apt install something and may be say yes or no. I am aware of apt -s.
4. I can't get why after removing some packages debian wish to install something as replacement. That way once I've got apache installed and starred at it while thinking what could led it to happen.

Yes, I am not an expert in Debian, but it makes me wonder more times, than I wish it to happen. There might be some ideas behind it, but _I am_ not capable to get it.
Arch is kind of restricted or binary Gentoo. It's a bit more cutting edge and has smaller user base, but my head is more compatible to it. Gentoo 10-15 years ago was perfect, after Daniel left it
it became a mess distro.
Head_on_a_Stick wrote:As debiman notes, this is clearly nonsense and you didn't pay attention to the terminal output before accepting APT's suggestion, that behavior will also break Arch, FWIW.
Nope. Debian is not aware of groups. Packages within one group are not in dependence relation to each other. They all installed manually, but at once. Deleting of any signle of them should not lead to uninstall others. Installing GNOME might bring up network-manager, but uninstall of GNOME should not kill the latter. There is no dependency between two! And there is none one who can disagree on it.
Head_on_a_Stick wrote:It is worth noting here that the nvidia-driver package is not part of the official release and is only provided as a convenience so perhaps you are expecting too much here, a similar argument can be applied to backports: the devs focus on older hardware rather than shiny new crap (and I applaud this approach).
I do not blame any one. Debian has to stay the way it thinks fine for developers. My only wish is to enable backports repo as any other repo available in the system.
It is disabled by default - fine. Tell me how to enable it if I wish to. End of discussion.

Head_on_a_Stick wrote: You don't because that is a very silly idea: as you have seen the dependency tree in backports may not be complete so favouring them by default would break your box on a boringly regular basis :roll:
Wait. The manual said, that backports are packages build with stable libs. Why it should be a problem? I have failed with only one.
Head_on_a_Stick wrote:
The problem has been discovered with linux-headers
^ This is more vexing, the headers should be installable.
They are. I had to add -t stretch-backports to succeed. It was my fault if that special option is required. The same option doesn't work with nvidia-driver. And I worry if it might not work with other packages too.
Head_on_a_Stick wrote: Remove that stupid preferences file, run `apt update` and then use the recommended method to install the backported headers:

Code: Select all

# apt install module-assistant
# m-a prepare
^ This presumes that you are already booted with the backported kernel.
I can't boot. I am in chroot. There will be no boot, till everything works.
Last edited by lefsha on 2018-06-16 17:27, edited 1 time in total.

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

Re: stretch-backports - how to enable automatically?

#17 Post by lefsha »

Head_on_a_Stick wrote: Why have you added proposed-updates?
Not a question. Just masked it with #. No change.

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

Re: stretch-backports - how to enable automatically?

#18 Post by lefsha »

Trying again with logging the results here:

Code: Select all

apt -t stretch-backports install nvidia-driver

Code: Select all

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: xserver-xorg-video-nvidia (= 390.48-2~bpo9+3) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

Code: Select all

apt -t stretch-backports install xserver-xorg-video-nvidia

Code: Select all

Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  glx-alternative-mesa glx-alternative-nvidia glx-diversions keyboard-configuration libdbus-1-3 libdrm-amdgpu1 libdrm-common libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libedit2
  libegl-mesa0 libegl1 libegl1-mesa libepoxy0 libexpat1 libfontenc1 libfreetype6 libgbm1 libgl1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libglvnd0 libglx-mesa0 libglx0 libice6
  libllvm5.0 libnvidia-glcore libpci3 libpciaccess0 libpixman-1-0 libpng16-16 libsensors4 libsm6 libwayland-client0 libwayland-server0 libx11-6 libx11-data libx11-xcb1 libxau6 libxaw7
  libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-sync1 libxcb-xfixes0 libxcb1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxfont2 libxkbfile1 libxmu6 libxpm4 libxshmfence1
  libxt6 libxxf86vm1 nvidia-alternative nvidia-installer-cleanup nvidia-legacy-check nvidia-support pciutils update-glx x11-common x11-xkb-utils xkb-data xserver-common xserver-xorg-core
Suggested packages:
  nvidia-driver lm-sensors xfonts-100dpi | xfonts-75dpi xfonts-scalable nvidia-kernel-dkms | nvidia-kernel-source
Recommended packages:
  dbus xfonts-base xauth libpam-systemd nvidia-driver nvidia-vdpau-driver nvidia-kernel-dkms | nvidia-kernel-390.48 nvidia-settings
The following NEW packages will be installed:
  glx-alternative-mesa glx-alternative-nvidia glx-diversions keyboard-configuration libdbus-1-3 libdrm-amdgpu1 libdrm-common libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libedit2
  libegl-mesa0 libegl1 libegl1-mesa libepoxy0 libexpat1 libfontenc1 libfreetype6 libgbm1 libgl1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libglvnd0 libglx-mesa0 libglx0 libice6
  libllvm5.0 libnvidia-glcore libpci3 libpciaccess0 libpixman-1-0 libpng16-16 libsensors4 libsm6 libwayland-client0 libwayland-server0 libx11-6 libx11-data libx11-xcb1 libxau6 libxaw7
  libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-sync1 libxcb-xfixes0 libxcb1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxfont2 libxkbfile1 libxmu6 libxpm4 libxshmfence1
  libxt6 libxxf86vm1 nvidia-alternative nvidia-installer-cleanup nvidia-legacy-check nvidia-support pciutils update-glx x11-common x11-xkb-utils xkb-data xserver-common xserver-xorg-core
  xserver-xorg-video-nvidia
0 upgraded, 73 newly installed, 0 to remove and 18 not upgraded.
Need to get 42.5 MB of archives.
After this operation, 280 MB of additional disk space will be used.
As you can see it works if installing one by one, but as dependency doesn't!

Issue reported:

Code: Select all

W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168h-2.fw for module r8169
It's just fine. We do:

Code: Select all

apt -t stretch-backports install firmware-realtek
Few more steps with -t stretch-backports

Ha! I guess, I've got it. I have to provide each time "-t stretch-backports" to keep things working!
I was thinking it is required only for packages from backports. Nope. It will screw up my system.
If any problems will come up again - I will report. The main question remains the same - how to
make "-t stretch-backports" by default without actually typing it.
Another fact nvidia-driver dependency is broken with "-t stretch-backports" enabled.

Not really happy, but will mark it as solved. Thanks to every one! Debian has survived that fight... :D

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?

#19 Post by Head_on_a_Stick »

lefsha wrote:
Head_on_a_Stick wrote: Not true: you could add stable, testing or even experimental repsoitories to your sid system and pin older versions from there ;)
Too much work. Too high risk to fail.
+1, I agree, Debian stable is *much* easier to manage :)
Actually I was fine with sid only
Yes, it is surprisingly usable for a development branch, using it for a server would be sheer foolishness though.
if base is broken by default, then yes it is broken, otherwise it is not. In other words it is broken as much as "debootstrap stretch /mnt/linux" can be broken.
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.
While doing a simple "apt install package" I am always missing:
1. Dependency tree, which I can get with emerge -t
2. Versions of packages going to be installed, which I can get with emerge -a
3. There is no way to list installing package if it is the only one before installation to confirm it or prevent it - emerge -a
In many cases I wish to see what will happen if doing apt install something and may be say yes or no. I am aware of apt -s.
4. I can't get why after removing some packages debian wish to install something as replacement. That way once I've got apache installed and starred at it while thinking what could led it to happen.
  1. The dependency tree is only guaranteed to be complete for the stable release, no such assurances can be made for backports because of the dynamics of the packaging system in the development branches.
  2. Package versions can be shown with APT, please consult the relevant man pages.
  3. Why is `apt -s install` not good enough?
  4. Please read that link about metapackages in my last post, it is rather annoying that I have answered this and yet you still bleat on...
Debian is not aware of groups
No, Debian doesn't have groups (although they can be simulated with tasksel) but I was actually referring to the fact that Arch Linux also offers metapackages:

https://wiki.archlinux.org/index.php/cr ... and_groups
My only wish is to enable backports repo as any other repo available in the system.
Pin the repository to 500, then it will match the stable repository pin value and APT will prefer the newest package version available.

This will break your box next time you `apt upgrade` though ;)
The manual said, that backports are packages build with stable libs. Why it should be a problem? I have failed with only one.
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.
Head_on _a_Stick wrote:Why have you added proposed-updates?
Not a question. Just masked it with #. No change.
And how do you know if any depencies have already been pulled in from that repository and polluted your chain?

Also, did you `apt update` after removing the line?

Finally:
I have to provide each time "-t stretch-backports" to keep things working!
Did you actually try `aptitude` instead of `apt`, as suggested several times?

The superior dependency resolution algorithms of that program may have offered the desired solution.
deadbang

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

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

#20 Post by lefsha »

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
well it can be repaired by:

Code: Select all

apt-file search dpkg-architecture

Code: Select all

dpkg-dev: /usr/bin/dpkg-architecture

Code: Select all

apt -t stretch-backports install dpkg-dev

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