FESco meeting summary for 20090605

[Toshio Kuratomi]

On 06/08/2009 01:06 PM, Simon Wesp wrote:
> Am Freitag, 05 Juni 2009 12:21:01 schrieb Kevin Fenzi:
> KF> 17:28:03 <notting> so, we already have -5 to the exception for zsync
> KF> 17:28:28 <nirik> #agreed No exception for zsync.
> 
> Of course shipping internals is very very evil and I really understand the problems behind them. 
> 
> I'm a pessimist and I ask myself: 
> "What is the consequence, if rsync-upstream is unwilling to drop shipping of forked zlib as internal dependency?" 
> a) drop rsync from fedora?
> b) build rsync against system and lose compatibility to rsync original?
> c) call the dependency rsync-zlib or whatever?
> 
> The zsync difficulty is that zsync tries to be compatible to rsync and needs a forked zlib, like rsync. It's on the dice, that the zlib-internal is bound with the zlib of rsync. I beg, again, for the exception of zsync, because the problem wouldn't be worsened.

This is the wrong solution to the problem.

> It's just a new child of sorrow, sitting in the front of the closed door and knows his brother with the same misfeature is in.
> If rsync-upstream is unwilling to drop internal zlib, I believe nothing will happened, because rsync is a centerpiece of every distribution and fedora can't afford drop this package or can't afford to be incompatible to other distributions and rsync itself. And renaming the zlib for this project will bring a flood of *-zlib and that can not be the meaning of it all.
> 
simo told notting that it was possible to fix this.  So we need him to
give some input on how he's thinking this can be done.  However, we are
going to fix this somehow.  If don't have a clean method, we'll have to
fork zlib.  Robert, I still haven't heard, what happened when you asked
rsync upstream about their releasing their forked zlib separately?

Having a flood of zlib-* is unlikely to happen at the distribution level
because the effort to maintain all the libraries is painful.  It's more
likely that we'll make more of an effort to work with upstreams to port
their code to vanilla zlib and work with the patches to zlib that they
carry to get them merged upstream.... and if those patches can't be
merged, to get them merged into a single fork rather than multiple forks.

> I think this is an important question. I don't want to bring trouble upon fedora project or rsync or anybody else. Additionally, I believe that there are a few applications in fedora which are using shipped internals, too.
> As I said it before, I don't want to start trouble, but it should be very helpful to find them and collect them in a seperate tracker. I created one with the bugnumber #504497 to get an overview, about packages/applications with duplicated libs. Please help to find them. Perhaps we can be succeed in conversion of upstream, to help all for a better cooperation and better software. Thank you!
> 
Yes, please, if you know of a package that's shipping an internal
version of a library, open a bug and block the tracker so we can fix it
(or possibly get FESCo to issue an exception).  These things should be
getting caught during package review but sometimes they slip through the
cracks.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090608/c4cb6a44/attachment.sig>