Hi Damian: Responses are interspersed below: On 12/11/2012 03:31 AM, Damian Minkov wrote: > 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 <tmancill@debian.org > <mailto: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> <mailto: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 I pulled the new version, thank you for pulling those out. (That saves 8MB on the orig.tar.gz.) > > 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. Within Debian, I think the best course of action for libraries that need updates is to file severity wishlist bugs against those library packages. Sometimes maintainers will upload newer versions of libraries to experimental, which will allow you continue development (although it means that your package would also go into experimental, at least for the time being). If you wanted to, you could even block your ITP bug with update requests. libavcodec was one example (that might problematic), but there are others that I think can be resolved. lcrypto appears to be bouncycastle 1.43, and Debian already has 1.46 in unstable [1]. Is there something about the embedded copy that differs from the upstream bouncycastle? portaudio is also packaged for Debian [2]. I haven't had a chance to check all of the others yet. > 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? I don't think it's unreasonable for libraries that are currently specific to jitsi and have the same upstream (others may disagree). But for libraries that have distinct upstreams, I think it's important that they be separate packages (again, if others disagree, please chime in), even if they're not currently part of Debian. Without that, it becomes difficult to determine what package needs to be updated when there are security issues with a particular library. Second, it helps the community at large to have useful libraries packaged. (That's with my Debian hat on - I recognize that it can be a lot of work.) Also, it helps establish the provenance of those libraries. For example, I'm not sure looking at the debian/copyright for jitsi where to look for the upstream of macwidgets. The fact that you have all of the project dependencies building from source means that much of the work for these dependency libraries has been done, and it's impressive too! I think some of these libraries - for example gdata-java-client - could/should be maintained by the Debian Java team. I'll continue to take a look to see which of these might already be or should be packaged separately in Debian. Cheers, tony [1] http://packages.qa.debian.org/b/bouncycastle.html [2] http://packages.qa.debian.org/p/portaudio19.html
Attachment:
signature.asc
Description: OpenPGP digital signature