On Thu, May 27, 2021 at 11:18:28AM +0100, Simon McVittie wrote: > On Thu, 27 May 2021 at 08:30:11 +0200, Simon Josefsson wrote: > > I do think it would be a wortwhile release > > goal, at some point, to fix tooling so that dummy packages are no longer > > necessary for package transitions. > > Transitional packages have the huge advantage that they already work > (and the reason they work is a side-effect of how ordinary non-transition > upgrades work, so it isn't going to go away). Making them unnecessary > seems likely to be more code (therefore more bugs), so it would have to > be counterbalanced with a real advantage. If we are replacing a "real" > package with a transitional package, then by definition that package > name is no longer in use, so having the transitional package "occupy" > the name is harmless. So, here is a thing: I like transitional packages – because it means the package is not removed. The thread kinda claims that apt has problems with removes and in some way it has, but it is actually one of the more relaxed ones as its greedy solver can also decide to remove too much… Users can be really averse to package removals. And we reinforce this with things like "upgrade vs. full-upgrade". Many solvers take the amount of packages to be removed as a prime indicator for how "good" a solution is. The result is that a clever solver (which apt is not) can decided to upgrade KDE3 to GNOME instead of KDE4 because the later would remove more packages (that isn't to pick on either desktop environment or other solvers, its just a colorful and simple stupid example which actually happened while people tried to show how bad apt is compared to a SAT solver years ago). So, I think this is not so much about teaching software and users alike that there exists an upgrade path without a transitional package, but that a given package removal is "okay" as you don't loose features which is the main fear of users. The knowledge can usually be found somewhere deep in a bugreport or the changelog of a package and if you are super lucky in the release notes. Same for "not okay, but required" removals like python2 stuff obsoleted by two other apps to 70% each… > The one non-cosmetic reason I can think of why transitional packages > are potentially bad is that they aren't removed automatically, so systems > that have been upgraded many times can end up with a lot of transitional > packages; not needing transitional packages would make > https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#obsolete > somewhat less necessary (although still necessary, to deal with packages > that were removed with no direct replacement). That doesn't seem hugely > compelling to me? A transitional package can be semi-automatic removed by autoremove like any other package if nothing has a positive dependency on it anymore, is not manually installed and not priority required or "worse" (aka essential and such). A package which switches its section to 'oldlibs' can even get rid of its own marking as manual, as if it has this marking it will move the marking to the package(s) it depends on and mark itself as automatic installed (in apt and "normal" libapt users at least, never tried with aptitude which is an "unusual" libapt user). And as a sidenote, in bullseye apt supports patterns similar to aptitude, so e.g. ~o works as noted in the release notes in apt now. dpkg has the notion of "disappearing packages" (packages which have no files left on a system) which could solve this cleanup compulsion, but it is currently not supported (as in forbidden in practice) in Debian. > If you want to pursue this, the right way to do it would be to send a > bug report to apt. I'm not sure how feasible it is to make superseded > packages identifiable and make apt assign a more favourable "score" > to removing them, but apt maintainers would know. One possible route > would be an equivalent of rpm's Obsoletes field. Fun fact: apt has some support for rpm's Obsolete, but mostly from a failed attempt to merge apt-rpm decades ago and probably entirely broken if we would actually end up using it. ABI wise it exists though. From the same area came support for versioned provides by the way, but I had used that years before already for implementing MultiArch in APT in 2010 before it was made available to the general public (another apt internals thing is the "libsame breaks (!= 1)" also used by M-A). The problem with Obsolete and giving it too much value is a bit about social issues like "vim obsoletes emacs" and that transitions tends to not be that clear cut like multiple forks/package splits and at times transitions are even rolled back a few months later… so the clear upgrade path we tend to imagine here looks in practice more like the tricky mess which results if you put three cables neatly separated in a box and you look away for a split second… > If it's feasible to solve this, then I suspect the only packages that > would need code changes would be apt and cupt (and maybe aptitude). I guess you would also need to change external solvers like aspcud, but those usually do not concern themselves too much with upgrades, but are mostly used in build-chroot constructions, so you might get away without it (see also optimisation criteria "less removals" from above). As the number increases we would also need an "upgrade" command which allows those removes but not the others as our current "upgrade" becomes less and less useful. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature