[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Planning for libidn shared library version transition

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

Reply to: