[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.


[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

Reply to: