>>>>> "KL" == Kalev Lember <kalevlember@xxxxxxxxx> writes: KL> If texlive packaging is causing issues with update pushes, could KL> maybe ask the texlive maintainers to rework the packaging? The texlive packaging is basically the way they were required to do it way back when. It used to be just a big ol' "texlive" package with only a few subpackages that bundled up countless different upstream packages. Now it's a big ol' texlive srpm that bundles countless different upstreams, but then splits each of those upstreams into a subpackage. A better way from a packaging standpoint, but not the happiest outcome for our infrastructure folks. And in a lot of ways it's similar to how Perl works, where there's a big "distribution" that contains some stuff, and a bunch of collected packages which are also available from separate upstreams. However, imagine how much the world would hurt if we just had one SRPM for CPAN with thousands of subpackages. What texlive needs now is to have a bunch of the packages split out. They all have separate upstream tarballs and such and most don't change, well, ever. But that means a thousand package reviews. So, fun. And every time you split one out.... you have to re-rev the entire texlive world. Even if we split out the largest, uhh, 50 texlive components, that would still make only a tiny dent in the number of packages that would have to be mashed when the main texlive package updates. And from what I've seen, most texlive updaates aren't made due to changes in some subsidiary texlive package, but becuase of structural changes to the main texlive package. And I'm not sure if that would also require bumping the subsidiary packages. But, sure, if someone cares about texlive, try to split out one or two of the major packages. See how it works and if it helps. (Though one package can't really help measurably; you'd have to do a hundred.) You can always merge them back in later if it turns out to be a horrible idea. - J< -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
