Following a number of reports that lib sources are necessary when
packaging Jitsi for various repositories, we are about to start
committing them to SVN.
Damian we'll shortly create a libsrc directory next to trunk (so that
people don't have to download all lib src zips when checking out the
Please make sure that from now on, every time you add or modify a lib in
the lib/ directory, you also commit the sources you obtained it from in
the libsrc directory.
thank you very much for caring about third party packagers. But are you sure,
that the third party packagers really wanted you to copy the source code of
third-party libraries from their original location to your repository?
The reports that I've seen was that in some cases it is hard to get hold
of the version that we use in Jitsi, either because the project has
moved on, or because it is simply no longer available.
This could be pretty embarrassing in some cases as it jeopardizes
At least for Debian I'm pretty sure that this does not help but may rather
make packaging even more complex. If you're talking about third-party
libraries (like ffmpeg) then Debian would like to reuse the already packaged
ffmpeg instead of packaging it again as part of jitsi.
It would help a lot, if you could remove all library binaries (.so, .jar) from
the jitsi source code tarball and also from SVN. Instead you could rely on Ivy
or Maven to retrieve java dependencies. I don't know for C dependencies, but
many other projects also manage without bundled third party binaries.
I am aware of the preference that the Debian crowd has for reusing libs.
As much as this may make sense however it simply doesn't work for Jitsi.
We repackage most of the jars while building packages because we either
include them in our OSGi bundles or turn them into such. Unfortunately
there's no way we could refer to an existing jar and load it in Felix
(our OSGi impl) without modifying its manifest.
We do the same for native libs although there might be away around it in
this case. I think Ingo had some observations in this case.
Now, even if we find ways of addressing the above two, this still leaves
us in a delicate situation with libs that we have modified ourselves in
order to better suit the way we use them in Jitsi. Our versions of
smack, portaudio and ffmpeg for example all come with such modifications.
Last but definitely not least, I am quite worried about the versioning.
Forcing use of distro packages only is going to cost a lot in terms of
maintenance and making sure that we work with the lib versions that are
available on the various distros (if at all possible).
On the other hand, adding sources to our repo would at least allow
whoever's interested to provide a complete src package for Jitsi.
Hope this makes things clearer.
On 29.02.12 11:21, Thomas Koch wrote: