Hi Tony, thanks for the quick comments on our package, we have some questions:
On Tue, Dec 11, 2012 at 7:14 AM, tony mancill <[email protected]> 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 <[email protected] <mailto: > [email protected]>> > > * 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 > > >
