Ralf Corsepius <rc040203 <at> freenet.de> writes:
> Are you seriously telling me you would accept a package which has 30 or
> more patches applied?
Why not? In fact, there are already such packages in Extras. For example, look
at the ATLAS package. That one uses the "one big patch" approach, because there
would be too many otherwise: there's a Debian gzipped patch applied which is
3.8 MB _compressed_ (!) and then there's a 972 byte Fedora patch on top of that
to use gfortran instead of g77. Some packages have upstreams which are either
defunct or (as is probably the case of ATLAS) don't care about packaging and
packagers' requirements, so there's no other solution there. Sure, if the
patches could go upstream, it would be better, but if not, I don't see why
having many or big patches would be a reason not to approve the packages.
Also, for a package like rtems-binutils, upstream is really RTEMS, not the FSF.
So the big patch to get from FSF Binutils to RTEMS Binutils is not really a
packager patch, it's just how upstream distributes its source code. Getting
their local patches merged into the FSF source is something upstream would have
to deal with, not the Fedora packager. TIGCC works similarly. (I currently have
a 318 KB GCC patch and a 61 KB GNU as patch.)
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
