On 09/15/2009 12:14 PM, Adam Jackson wrote: > On Tue, 2009-09-15 at 11:27 -0700, Toshio Kuratomi wrote: >> On 09/15/2009 06:55 AM, Adam Jackson wrote: >>> On Tue, 2009-09-15 at 13:44 +0200, Josephine Tannhäuser wrote: >>>> Hey, >>>> >>>> I googled for it and found Karims blogpost and Simon aka kassamedias >>>> answer (comment 3) >>>> >>>> http://kparal.wordpress.com/2009/09/01/zsync-transfer-large-files-efficiently/ >>> >>> If we _really_ cared about doing this OAOO, we could probably get the >>> rsync package to drop out its own zlib copy as a shared lib, make that a >>> subpackage, and link zsync against that. >>> >>> But, for 74k of shared library, I just don't care that much. This >>> shouldn't block packaging zsync. >>> >> The rules against shared libraries aren't because of saving space:: >> >> https://fedoraproject.org/wiki/No_Bundled_Libraries > > I'm aware, I just don't think they read strongly enough on this case to > matter. The copy of zlib is there _because_ it can't change, so the > arguments for changing things OAOO are really weak. > Uhm.... Why can't it change? For instance: zlib upstream has buffer overflow. We issue a zero day update. Woo hoo, go us. After a few weeks rsync upstream notices that zlib has been updated. Applies their patches to their copy of zlib. We make a zero day update of rsync... but the vulnerable version has been out there and known for several weeks. Now zsync notices that the zlib in rsync has been updated. They update their version of zlib. We release yet another zero day update... but it's been even longer that the vulnerability has been published at this point.... > I'm also not aware of any precedent for what to name a library like > this. %{_libdir}/libfedora-rsync-zlib.so.0 ? What version number do we > pick? Who's responsible for making sure it gets bumped when it should? > Seems like a lot of policy to type for very little practical gain. > All of these are reasons that people have been trying to get upstream to manage the forked library instead of forking it here. However, last time I checked no one has contacted rsync upstream to see if they're willing to support the forked library in their packaging. So we're at a point where no one is doing the work to make this happen... either upstream or locally. > Speaking more generally, the package review process makes it very hard > to get anything in the door if it doesn't fit the existing rules, and > the rules do not change quickly. We would probably deliver more value > if we were willing to accept packages with merely a _plan_ to fix the > deviations. As a bonus, we'd have a list of things to do for people > looking for ways to contribute. > 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. -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
