Python 3 restore alternatives

[sgn]

No description provided.

[ahesford]

You can drop python3-tempora and python3-Cheroot, I'm updating them and have added the alternatives there. #25614

[q66]

what, what's the point of this? why ship alternatives if we've deprecated python 2 anyway?

[ahesford]

Because it causes needless conflicts for users who still have the py2 packages installed. Those packages still define alternatives with symlinks that conflict with the scripts in the py3 packages. It's either we carry forward the alternatives, or we add empty transitional packages for the py2 packages to eliminate the alternatives and, thus, the conflict.

[q66]

either have the users remove the py2 packages (by making the py3 packages conflict) or make transitional packages, the alternatives system is terribly bug prone and carrying alternatives for things is both pointless and potentially dangerous

[ahesford]

Conflicts are the current behavior, but that seems suboptimal. I'm OK with transitional py2 packages but others may have an argument against that. Note that these alternatives already existed in the unified py2/py3 packages, they are just being restored in the standalone py3 packages that were split off.

[q66]

yes, i know they existed, and they were always a bad idea, so i see no reason to go back to them

we've always been doing transitional packages for removals, and for a good reason, leaving them behind just creates a huge mess (especially considering the repos are never cleaned, so old packages just linger); we've stopped when @Chocimier started loudly objecting against it, and IMO the situation now is worse than it was before, and noone else really ever objected as far as I can recall - I still think doing them at very least in pain-prone situations is better than not, considering xbps has no facilities for resolving this

[Chocimier]

I am not much again transitional packages, where packages they pull are viable, compatible replacements for removed ones.
I am strongly against removing packages by revbump installing empty package. This breaks users workflow without any clue what happened. This is hostile. Some @void-linux/pkg-committers seemed to agree.

That's true that xbps have no ability to make removal explicit, so let's add it. I am slowly working towards it since over year, thinking exactly about python2 drop back then.

"Xbps can't" shouldn't be eternal excuse for disrupting user's work.

[sgn]

In my opinion, we should either be clear that python2 version is unsupported, users that want those python2 need to install them explicitly (via pip), so that's reason of conflicts.

However, it's disruptive and makes users' life harder (to upgrade), thus this PR.
This is a scripted-effort to solve the problem.

[q66]

@Chocimier i don't disagree that this is a non-ideal situation, but we probably shouldn't be doing stuff that actually creates a bigger mess while xbps still doesn't have any solution for this

also, i don't think the argument holds for python2 packages either way; python2 is on its way out, and arguing with "disrupting users' workflows" is pointless since sooner or later these packages will create conflicts with other stuff in the system (well, they already are, which is the point of this PR in the first place)

@sgn if you want to make this smoother, just provide transitional packages to python3 variants, but i think keeping the conflicts is fine, it requires manual intervention from the user but also is relatively obvious

[sgn]

@sgn if you want to make this smoother, just provide transitional packages to python3 variants,

I don't really like the transitional packages for this case, provides a fake update to remove things is not nice, and python-foo that depends on python3-foo makes even less sense.

but i think keeping the conflicts is fine, it requires manual intervention from the user but also is relatively obvious

This was my line of thinking when I added the conflicts. I strongly prefer to keep the conflicts (since without conflicts tag, I see enough file conflict in other packages).

[Chocimier]

So for this PR I'm fine with alternatives, fine with replaces, fine with reintroducing python-* as transitional packages pulling python3-*, as most are primarly command line tools for which python version is secondary, quite fine with leaving conflicts as is.
But I'm not fine with reintroducing python-* as empty meta packages pulling nothing, because this on installations where only py2 version is present, system update will silently remove tools that was installed purposefully (rather than as dependency).

For future, i would propose not to remove packages unless absolutely necessary before xbps can tell to user that package will be uninstalled.
This is not very far. This requires signing repodata and some polish of void-linux/xbps#162 .

[sgn]

Look like there're people support conflicts. I'm closing this PR.