De: "Jakub Cajka" Hi Jakub > I'm strongly against general unrestricted practice of compat packages as proposed. If you need compat package you > need to work with usptreams on stabilizing the API/project, fork it, or just use COPR as your projects(or its > dependencies) are not yet mature enough for Fedora. I appreciate the sentiment, and I quite hate compat packages, but the restrictions you want did not work in practice for Fedora. Making compat package creation hard does not result in faster fixing to use new code. What it actually does is to block the packaging of all the projects that need a more recent package state, because packagers that need the old state for one of their packages, will drag their feet on updating common dependencies till the code of their packages is fixed upstream, or they have the time to fix it themselves. And blocking packaging of new part means you do not get the new packagers that would join because they're interested in the new parts, and would contribute to the maintenance of common deps (not all of which need compat-ing), and would relieve part of the pressure on the existing packagers, that prevents them from working as much a they'd like to on updating their packages. It's a death spiral. It results in a massively obsolete Go package baselines, full of holes, because all the energy is poured in making existing stuff work, at the expense of onboarding new packages and packagers. Regards, -- Nicolas Mailhot _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
