Zbigniew Jędrzejewski-Szmek wrote:
So... building multilib packages is still very much supported. You
cannot
*run* a pure-i686 environment, but you can 32 bit development.
You have to configure a slow, non-mirrored repository for that instead of
just using the same mirrored URL pattern (with $basearch substituted
automatically) as for the still fully supported architectures. And there is
no real technical reason to do that, the only goal was to deliberately
inconvenience users attempting to use the software.
> * the insane proposal to require AVX2 for x86_64, which has
thankfully
> not been implemented so far, but against which we will likely have to
> fight again and again during the next few years,
This proposal was rejected very forcefully. fedora-devel was unanimous
with >100 messages, which I have never seen apart from that once case.
If it get's proposed again, you can expect the same result.
I have seen several features with similarly overwhelmingly negative
fedora-devel feedback that were waved through by FESCo anyway. (See, e.g.,
Modularity, where from the beginning, I and others had pointed out the
provably unsolvable flaws in the core design axioms, which, very
unsurprisingly, materialized exactly as predicted, see
https://communityblog.fedoraproject.org/modularity-vs-libgit/ . All this did
not prevent the feature from getting approved and implemented.)
Well, yes. Unmaintained packages are retired. Sorry, but it's
either that
or development of new things in Fedora stops, because every change is
hamstrung by uninstallable and unbuildable packages. We just can't have
packages with no maintainers.
Most packages with no maintainers actually still just work (without even a
rebuild). Some require a trivial rebuild. Only a handful are actually
broken, and those are reasonable candidates for a removal. But removing
working packages only for the lack of a maintainer serves no purpose and is
a pure disservice to the users of the package.
There is often no reasonable alternative tool for the purpose. So what are
the users of the removed package supposed to do?
Those removals are not quick: FTBFS packages are retired after
*months*,
orphaning usually only happens when there are long-standing unresolved
bugs. In most cases, the package is bitrotting for multiple releases
before any removal happens.
Orphaning usually happens because the maintainer explicitly orphans the
package. The policies then leave only 6 weeks for the package to get adopted
before it will get retired! That is not "long-standing" at all.
And if an otherwise maintained package FTBFS, if it does not actually need
any change, I don't see how this is even an issue at all.
That's very much unfair. The python team has put an _insane_
amount of
work into telling everyone about the transition, planning all the
steps, filing bugs, retiring leaf packages first, asking for feedback,
fixing bugs, etc, etc, etc. "Agressive" would be all python2 packages
were simply dropped after F32 branching.
If only they had instead put such an "_insane_ amount of work" into actually
maintaining, and committing to maintain for at least 5 to 10 more years, the
python2 compatibility package, which is actually not work-intensive at all
(just backport security fixes from Python 3 as they happen, which they'll
likely have to do for RHEL anyway).
Instead, a lot of time was wasted spamming everyone about the impending
scorched earth "transition", quickly getting an unreasonable "plan"
with a
totally insufficient transition period rubber-stamped by FESCo, dropping
random leaf packages they hoped nobody would notice (when actually, those
leaf packages are the whole reason we need the compatibility stack to begin
with; the leaf packages are what the users actually use and need!), ignoring
all feedback (at least all that did not just blindly agree with their
nonsense "plan"), "fixing" "bugs" (typically just removing
Python 2 support
from random packages in the hope nobody would notice), etc., etc., etc.
See qt (4) and kdelibs (4), and qt3 and kdelibs3, for how compatibility
should work.
So sorry, but you can't expect every obsolete hardware technology
and
software stack from previous decade gets to hold everyone else hostage.
Compatibility is not "holding" anyone "hostage". Nobody is forced to
use old
hardware or compatibility libraries. The unilateral removal of such
"obsolete" technologies is what is holding users hostage.
Kevin Kofler