On Wed, Sep 18, 2019 at 5:25 PM Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > > 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. > This is true for building locally for i686. You cannot do 32-bit development with multilib x86_64 content. > >> * 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.) > The difference was the modularity only managed to make it in originally by being described as a purely add-on concept. It was individual packagers that started breaking the world by churning core packages into modules. Everyone knew up front that the hardware change was bad and there's no way to sneak that in without breaking people. It's not going in anytime soon. > > 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? > Become maintainers of the package? This is sort of the point of the system. Someone needs to take care of it, and if there's a user, they can become a maintainer. Ideally, most consumers of the package (dependency-wise) would consider at least being co-maintainers of their direct dependencies. > > 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. > It appears quick because we've have the FTBFS orphaning process be broken for three years. There's a lot of breakage to catch up on. Regular orphanings are happening because for some reason we allow orphaned packages to be used as inputs for modules, so now we have this giant mess of dead packages that aren't dead. This is a very broken policy and should be fixed, but I suspect that it won't be, because that would force module packages to always have a non-modular counterpart in the distribution, based on how our tools work. > > 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. > Those transitions had the benefit of the major consumer (KDE) moving forward relatively quickly after. Python 2 is not in the same state. In many cases, Fedora is the driver for packages getting ported to Python 3, and if we hadn't done it, it likely wouldn't have ever happened. This is one of the major things I consider valuable about Fedora. If we don't do it, I do not believe anyone else would. > > 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. > Look, if something is actually declared dead and unmaintained and there is an upgrade path, then it is on us to help everyone get through that upgrade path. That is literally the point of a distribution. We have a set of opinions of how the distribution is put together, maintained, and evolved. While I disagree with the removal of i686 content from the mirror network, I do not have the bandwidth to commit to helping the x86 SIG. This is why I'm not complaining about it. The folks that care about i686 should come together and revive the x86 SIG and fix bugs. I personally know that we have issues with Go and Rust based code on i686 because we keep hitting memory exhaustion during compilation. It also happens on armv7hl, but the ARM people add hacks for their platform to work. No one is doing the same for i686. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
