Hey man, apparently APT Pinning really does not account for release specific dependencies. (which is insane)
If you pin a package from a release (unstable) whose dependencies (versions) are not in the target release (stable), there will be a dependency error just like mine. The only reason why the Pinning example given in [Debian Live Manual](https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-package-installation.en.html#490) works is because all live-* packages (and their dependencies) in trixie have the same version numbers in unstable: Package: live-* Pin: release n=sid Pin-Priority: 600 Package: * Pin: release n=sid Pin-Priority: 1 Any other time you want to build stable or an older target release, while including only a single or a few packages from unstable, you literally cannot use APT Pinning. Because it will either return the dependency error (if Priority is lower than target release), or simply install every single package from unstable (if Priority is higher than target release). So from what I understand, the only possible way to install only a single or couple packages from unstable, while installing everything else from stable is with a chroot hook that specifically installs the package from unstable with apt-get {/target_release} and gets all the dependencies from unstable too. APT Pinning cannot do this, if I am correct. Am I? Regards On Thursday, August 1st, 2024 at 7:19 AM, maria.shrivinski <maria.shrivin...@proton.me> wrote: > Hey man, > > apparently APT Pinning really does not account for release specific > dependencies. (which is insane) > > If you pin a package from a release (unstable) whose dependencies (versions) > are not in the target release (stable), there will be a dependency error just > like mine. > > The only reason why the Pinning example given in [Debian Live > Manual](https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-package-installation.en.html#490) > works is because all live-* packages (and their dependencies) in trixie have > the same version numbers in unstable: > > Package: live-* > Pin: release n=sid > Pin-Priority: 600 > > Package: * > Pin: release n=sid > Pin-Priority: 1 > > Any other time you want to build stable or an older target release, while > including only a single or a few packages from unstable, you literally cannot > use APT Pinning. Because it will either return the dependency error (if > Priority is lower than target release), or simply install every single > package from unstable (if Priority is higher than target release). > > So from what I understand, the only possible way to install only a single or > couple packages from unstable, while installing everything else from stable > is with a chroot hook that specifically installs the package from unstable > with apt-get {/target_release} and gets all the dependencies from unstable > too. > > APT Pinning cannot do this, if I am correct. > > Am I? > > Regards > On Thursday, August 1st, 2024 at 6:41 AM, Andreas Heinlein > <aheinl...@gmx.com> wrote: > >> Hello, >> >> it does make sense in the way that manually installing e.g. libavcodec61 >> with "apt-get install libavcodec61" and automatically installing it as a >> dependency produces the same results. >> >> What was apt expected to do if something else already had pulled in >> libavcodec61 from bookworm? Upgrade it, potentially breaking the other >> package? Leave it alone? You need to tell it somehow. >> >> I know this is sometimes tricky. I ended up multiple times downloading the >> source package from sid and rebuilding it for the current stable just to >> solve these dependency problems. >> >> Bye >> Andreas >> >> Am 1. August 2024 08:17:59 MESZ schrieb "maria.shrivinski" >> <maria.shrivin...@proton.me>: >> >>> Hello Andreas, thanks for the reply! >>> >>> The problem with adding mpv's dependencies to list.pref.chroot is that the >>> same error will occur again for the dependencies of those dependencies. >>> >>> libasound2t64 : Depends: libasound2-data (>= 1.2.12-1) but 1.2.8-1 is to be >>> installed >>> libavcodec61 : Depends: libcodec2-1.2 (>= 1.2.0) but it is not installable >>> Depends: libdav1d7 (>= 1.1.0) but it is not installable >>> Depends: libglib2.0-0t64 (>= 2.12.0) but it is not installable >>> Depends: libjxl0.9 (>= 0.8.0) but it is not installable >>> Depends: librav1e0.7 (>= 0.5.1) but it is not installable >>> Depends: libsnappy1v5 (>= 1.2.1) but 1.1.9-3 is to be installed >>> Depends: libsvtav1enc2 (>= 2.1.0+dfsg) but it is not installable >>> Depends: libvpl2 (>= 2023.3.0) but 2023.1.1-1 is to be installed >>> Depends: libvpx9 (>= 1.12.0) but it is not installable >>> Depends: libwebp7 (>= 1.4.0) but 1.2.4-0.2+deb12u1 is to be installed >>> Depends: libwebpmux3 (>= 1.4.0) but 1.2.4-0.2+deb12u1 is to be installed >>> Depends: libx264-164 (>= 2:0.164.3108+git31e19f9) >>> ............ >>> >>> I tracked down every single dependency (and their dependencies) with this: >>> >>> apt-cache depends --recurse --no-recommends --no-suggests --no-conflicts >>> --no-breaks --no-replaces --no-enhances mpv | grep "^\w" | sort -u >>> >>> Then I added them to list.pref.chroot but the error always comes back for >>> something else. >>> Package: mpv libasound2t64 libavcodec61 libavdevice61 libavfilter10 >>> libavformat61 ....... >>> >>> I found a dirty fix with a live.chroot.hook that installs mpv from >>> unstable and includes the correct dependencies from unstable too: >>> apt-get install -y mpv/unstable >>> >>> But that's not a solution. I would really like to understand why APT >>> Pinning does not or cannot include the dependencies of a package from the >>> release it is pinned to. Doesn't even make any sense tbh. >>> >>> On Wednesday, July 31st, 2024 at 8:56 PM, Andreas Heinlein >>> <aheinl...@gmx.com> wrote: >>> >>>> Hello, >>>> >>>> you will have to manually pin the dependencies as well. So it should read: >>>> >>>> Package: mpv libasound2t64 libavcodec61 libavdevice61 libavfilter10 >>>> libavformat61 >>>> Pin: release n=sid >>>> Pin-Priority: 600 >>>> >>>> That should do the trick. >>>> >>>> Bye >>>> Andreas >>>> >>>> Am 31. Juli 2024 21:06:22 MESZ schrieb "maria.shrivinski" >>>> <maria.shrivin...@proton.me>: >>>> >>>>> Hello, I would like to build with bookworm as the distribution while >>>>> installing the package mpv and ffmpeg from sid (unstable). >>>>> >>>>> According to the Debian Live Manual this should do the trick: >>>>> >>>>> config/archives/live.list.chroot >>>>> deb http://deb.debian.org/debian sid main >>>>> >>>>> config/archives/live.pref.chroot >>>>> Package: mpv >>>>> Pin: release n=sidPin-Priority: 600 >>>>> >>>>> Package: * >>>>> Pin: release n=sidPin-Priority: 1 >>>>> >>>>> This gives a low version error because live-build tries to install mpv's >>>>> dependencies from bookworm release, which has default Priority 500, while >>>>> sid now only has Priority 1 for anything but mpv. >>>>> >>>>> The following packages have unmet dependencies: >>>>> mpv : Depends: libarchive13t64 (>= 3.4.0) but it is not going to be >>>>> installed >>>>> Depends: libasound2t64 (>= 1.0.27) >>>>> Depends: libavcodec61 (>= 7:7.0) >>>>> Depends: libavdevice61 (>= 7:7.0) but it is not going to be installed >>>>> Depends: libavfilter10 (>= 7:7.0) >>>>> Depends: libavformat61 (>= 7:7.0) >>>>> ....... >>>>> >>>>> If I set the sid Priority higher or equal to bookworm's, all packages are >>>>> installed from sid because of higher version numbers. >>>>> >>>>> Is there a way to only install mpv including its dependencies from sid, >>>>> while all other packages are still installed from bookworm release? >>>>> >>>>> Thank you so much and have a nice day!
