Am Tue, Oct 15, 2024 at 08:12:44PM +0200, schrieb наб:

This configuration fresh-installs and upgrades fine for me on bookworm. I've updated the gits thus.

Looks fine to me too. Autoremove even picks up httpfs2 for removal. Neat. I didn't know that handles transitional packages!
$ apt-get autoremove
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
fuse httpfs2 libfuse2

I remember reading some manual that said to format transitionals like this, for "special handling", didn't know that was this. Cool!

fwiw libapt code (so most front ends with the notable exception of
aptitude and external solvers as this is part of the internal solving
they skip) recognizes if a manual installed package changes to section
oldlibs in an upgrade and if so marks new packages this upgrade caused
to be manually installed (normally they would be auto-installed) while
setting the oldlibs package to auto-installed.

This is a one time action (at the moment the package changes section),
so if a user for some reason wants to keep the oldlibs package installed
all they have to do is mark it as manual installed (again).


Without this feature the oldlibs package would not have been offered for autoremoval (as it would be still marked manual installed) and if the
user would ask for the removal of the old transitional package later autoremoval would "helpfully" suggest the removal of the transitioned-to package – easy to solve but probably not what the user meant.

The (re)move of the manual installation from the oldlibs package is
"new", I implemented that only 9 years ago (1.1~exp9), that oldlibs
new dependencies are marked manual is 14 years old (to prevent the
"helpful" suggestion mentioned earlier; not from me).


So, technically this isn't autoremove being clever, it is "just" some
code hidden deep in the internal solving that makes autoremove look
good later on – and one of the reasons why alternative solvers like
aspcud, solver3 or the one in aptitude have a hard time catching up.
Resolving Depends is (fsvo) easy, the fun starts with Recommends and
heuristics like this one.

(So, why not autoremove, you ask? It would need to invent a way for the
user to declare that they want to keep the transitional package anyhow
for example)

Bonus tip:
If you 'cheat' and test your upgrades with `dpkg -i` this and many other
things wont happen, so don't cheat, test them properly! If you don't
feel like setting up a repository you can skip that with e.g.
apt full-upgrade --with-source ./path/to/foo.changes


Best regards

David Kalnischkies

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE5sn+Q4uCja/tn0GrMRvlz3HQeIMFAmcSok4ACgkQMRvlz3HQ eIM+hA/7BFaWwQXCUS4lrAxvQGtQT23JlHrl3PTfhngTNLZSRPXxjFb/mP5Kf4rS /xDan4MJ6blXANw730xuKaVqWw3WyjQkD8MIVFH72zRt3TRpPmRuK/+qkQWi9MoU el+mHGTLCtaC72NVlBnNOB1zO+BdcwuRtwZ7rmYPDeKhYcoH3IOn2xH24R4tkh6K CTbssjcUC5RQQsFf6CyVq0kCQq3I2WmNcXj7SxcY9X4lRxbKEeFnlStBO90FqIn6 Mip3tIIie9ycUO7P5SEblxfqdkh0gTW/Ichf8tgtPPSPf/gabdP2Xw9MtPuDBqtd pGCMDOpuX1qFs8RKLNqXRRe5LhxSGB+ZuIG7V3+fHwbalZW7r67ATgB7xNDf7an4 YWSZBxwva0ktgco/0B3joo0cMugnevEksh2QcEPnCYr/9Cs/SvAR9oYk4/3KaYCm Rvp0F6P4dQ6kjjbgUsZ9dwWxAXVlrdaVDOYZIUKsatMfGwrHIscX6RSlMhfIInok o5FO5SrNF0FxTZVZ5WFWF6p8qCJkROP4qSeUesA3W596QqFvTsNtX3vknZAIHlrj TS+yMM+VSqi/W+UBVz8hTgtsFNaD4K3POcrPLxcJMAOludrIfvx9TNlSHVfOzBUv x7bgeOViqUTWP4fY/VdwCdWiAzXs6D3OBBjPBTURjmvas4rBT0g=
=W3wI
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi David,

On Fri, Oct 18, 2024 at 08:00:47PM +0200, David Kalnischkies wrote:

So, technically this isn't autoremove being clever, it is "just" some
code hidden deep in the internal solving that makes autoremove look
good later on – and one of the reasons why alternative solvers like
aspcud, solver3 or the one in aptitude have a hard time catching up. Resolving Depends is (fsvo) easy, the fun starts with Recommends and heuristics like this one.

(So, why not autoremove, you ask? It would need to invent a way for the
user to declare that they want to keep the transitional package anyhow
for example)

That's significantly more voodoo than I was expecting but it seems
reasonable :)

The only question I have is can we document this better? Looking through
the pertinent manuals (policy, devref, newmaint, debmake) I dont find any mention of these mechanisms. Am I missing some obvious place or keywords?

Devref only mentions deborphan but that's an entirely seperate thing as I understand it.

Bonus tip:
If you 'cheat' and test your upgrades with `dpkg -i` this and many other things wont happen, so don't cheat, test them properly! If you don't
feel like setting up a repository you can skip that with e.g.
apt full-upgrade --with-source ./path/to/foo.changes

Now I feel smart for always upgrade-testing with my full blown local apt
repo despite not having had any idea what's going on behind the scenes :D

Thanks for taking the time to explain this David, --with-source is also new
to me and was already super useful for libcurlfs upgrade testing :)

--Daniel

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEV6G/FbT2+ZuJ7bKf05SBrh55rPcFAmcvv1EACgkQ05SBrh55 rPfIKQ//RpVK/NK8az6QQs202T8uxpFUuSWV6UVAZ4otlstJPvs2gDQwjum2qPn5 DNptHHbqhPXsC+tChi+1IZVH2RcROqQiGo3JqimYtzPWG6kDnw/mTfZVMi5WRXvC J1cT+u9bvVC8pCz+FgQ/YlYSgsHhhVhQ0PYLmb4kmnBwcRKDS8QmYg7yfaCQVGjh mGFMyjLNPUXouGiyVVJ8Bm3/NTYvuEFiyWm8vUec9iPIeAryKoi1rLrZLTLonjXu uvDiO65lQMzWzPd/D5hVBUDoQDTMk8q0hoUdkErhszJOc55twLS0MrRez6khqX2x q6ogxfgwLNoUyGU9pVfLAbl6FSFvU27e7ICdzGpoX8oe6tIZLzCGVq/Kn+NhTToH ZSeXhf7v/nbBKFGivcVu7tkrsIxXay3t/dfqallS0FVTf/Hy/Rur9YKlyzskGdw0 Rk7S3N11/n6ebym5NEyzRIknEE5JcZIEEp7njSVa4y2X1Qs29QGQy9pw5HKSnpgs gC2OyuuJYQioYoChRX4x5BxqDBHixZx794h06v/IFQ6UGXIH2S8V1Y167KlgCO1E VD0NcJu5eLcXfpXoaWaMcWGyGdD9asYxHklAGEBE5ikAIxYkKSRWmyrttgkSRkZY /p6DQx9cyIU48RvunF5j0BG32qG2uDWy/gvGEKovQ79j2F5BBQc=
=DEEI
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)