On 09/15/2009 01:29 PM, Simo Sorce wrote: > On Tue, 2009-09-15 at 12:34 -0700, Toshio Kuratomi wrote: >> This would be great if maintainers were willing to fix issues after >> the >> fact. Look at rsync -- there's no incentive to fix the library issue >> at >> this point because rsync is already in the distribution. We need to >> fix >> this lack of incentive for other reasons -- but we need to fix it >> before >> we start trying to get more packages into the distro with less initial >> quality. > > Sorry but the packager may have no way to influence upstream. > And to be honest having a huge patch against rsync and/or zsync to > extract a library against the will of the rsync and/or zsync upstream is > contrary to fedora policy as (AFAIK). > You bring up several good thoughts here: 1) We have two conflicting policies. Stick with upstream and do not have private copies of system libraries. Since the latter is in place for security reasons and maintainability while the former is only for maintainability, I'd place more value on it. 2) There's huge patches and then there's huge patches. If we ported rsync to somehow use the system zlib and still be compatible with current rsync and that was not accepted by upstream, that would be one sort of huge patch. However, if we break zlib's rsync out into a subpackage and link rsync and zsync against that then that's a different kind of patch. The former is a patch against the code inside of rsync. The latter is a patch against the build scripts for rsync. We often make patches to build scripts because they aren't working in our environment. 3) The packager works for the distro and the consumers of the distro. If you can get upstream to acknowledge the burden they place on you and do the work to make it better then you are to be congratulated. You've made the world a better place for everyone. If you can't, then you need to do the work yourself for the consumers of your product. > And yes I am the maintainer of rsync and I am not doing the job, because > I don't want to have to create or maintain such patcheset until the day > I am reasonably sure upstream will want such patches. > This is wrong in attitude although it could be right in short-term practice. You are the representative of Fedora to upstream. You need to be doing work to try and get them to take a patch that satisfies our requirements. If they aren't going to budge in one direction, you need to try a different option. For instance, in this case we could try: (1) use system zlib instead of our forked copy and be backwards incompatible. (2) Use system zlib and find a way to be backwards compatible. (3) Use a forked copy of zlib and make that fork a separate project. (4) Use a forked copy of zlib and make that a dynamic library built out of the rsync package. If upstream isn't going to budge at all we need to decide whether we need to change the Guidelines or make changes locally. As mentioned making changes to fork out their zlib version has precedent so that's one way we could make changes locally. If you maintain the library (or get other distro maintainers to help maintain it :-) you can even send a patch back to rsync upstream to use that broken out library if configure discovers it at build time. If you don't want to do any of that work, then you have to come up with a good reason or plan for making a change to the Guidelines: Maybe your argument is: "Security is not a goal of Fedora, therefore, we don't need to worry about including forked copies of system libraries in applications." Or "We can mitigate the security risks by making all maintainers of applications which include system libraries also be maintainers of the libraries they are including and testing that they are capable of forward porting their patchsets to new versions of the system library they are including." Or "Including system libraries statically in an application is not a security risk, doesn't lead to forks, etc. The time that we had problems with zlib before was just a fluke and really it was the Martian brain-zappers that caused most of the problem, not zlib itself." Just asserting that there is no problem doesn't cut it. You have to mitigate the problem or prove that it doesn't exist. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
