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.
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.
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!
--
Mit freundlichen Grüßen aus dem schönen Hainzell
Simon Wesp
The G in GNU stands for GNU
http://fedoraproject.org/wiki/SimonWesp