Re: RFS: jitsi/1.1.4365-1 [ITP]

On Tue, Dec 11, 2012 at 7:14 AM, tony mancill <tmancill@debian.org> wrote:

On 12/10/2012 05:13 AM, Damian Minkov wrote:

> We are looking for a sponsor for our package "jitsi"
>
> * Package name : jitsi
> Version : 1.1.4365-1

> Upstream Author : Jitsi Community <dev@jitsi.java.net <mailto:dev@jitsi.java.net>>

> * URL : https://jitsi.org/
> * License : LGPL v2
> Section : net

> http://mentors.debian.net/package/jitsi
> dget -x http://mentors.debian.net/debian/pool/main/j/jitsi/jitsi_1.1.4365-1.dsc

Hello Damian,

I'm glad to see a package of jitsi. I've taken a look at the packaging
on mentors.d.o and I think there is some additional work to do before
the package can be included in Debian.

The first thing I would suggest is that the orig.tar.gz be repacked to:

a) not include binary JARs or .class files
- For example, there are 3 separate copies of junit alone.

Oh OK. They must have slipped in accidentally. We'll remove them in the next submission

b) exclude copies source libraries that are already packaged for Debian
- For example, libavcodec

We had a quick test with libav and we seemed to be missing some headers (as opposed to when using ffmpeg 1.0). We can give it another try and look some more. I am wondering however if we could somehow CC the corresponding maintainers and maybe have some feedback from them as well.

c) exclude copies of distinct libraries that should be packaged separately.
- For example, ice4j (even though you're also upstream for that), jsip

We completely understand the advantages of committing things into separate packages. The thing is that we started work on the Jitsi source deb package around the beginning of August and it has taken us that long to get here. We were hence hoping that we could work on getting the first version in its current form. We were planning on ultimately spinning off libs such as ice4j and libjitsi but given that no other projects are currently depending on them we were hoping that it could wait.

Is this unreasonable?

Thanks

Damian

I recognize that these may represent significant effort - particularly
(b) and (c) - given that the library versions in the source tarball
appear to be newer than the versions in Debian and that the libraries in
(c) will each become a separate package.

The reason behind (b) and (c) is the section Debian Policy concerning
"convenience copies of code" [1]. The reason for (a) is that the binary
artifacts needlessly bloat the archive.

This is the right list to help with (c), and (b) as possible for Java
packages.

Cheers,
tony

[1] http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles