How to manage/document C dependencies?
 

Hi,

I'm currently discussing with Jitsi[1] what they could do to make packaging
feasible. On the java site they'll now probably use Ivy to document and manage
their java dependencies.

But they also have a lot of dependencies to C libraries. These are currently
still committed to their SVN as .so files.

I'm totally clueless about C. Is there any best practice for an upstream how
to document your dependencies, their versions, license and download location
in a central place, maybe even machine parsable?

And what could upstream do to not rely on the .so files committed to their
repos? Provide a list of aptitude install *-dev commands required for a
developer?

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627362

Best regards,

Thomas Koch, http://www.koch.ro


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201111231015.41115.thomas@koch.ro">http://lists.debian.org/201111231015.41115.thomas@koch.ro

How to manage/document C dependencies?
 

Thomas Koch <thomas@koch.ro> writes:

> Hi,
>
> I'm currently discussing with Jitsi[1] what they could do to make packaging
> feasible. On the java site they'll now probably use Ivy to document and manage
> their java dependencies.
>
> But they also have a lot of dependencies to C libraries. These are currently
> still committed to their SVN as .so files.
>
> I'm totally clueless about C. Is there any best practice for an upstream how
> to document your dependencies, their versions, license and download location
> in a central place, maybe even machine parsable?
>
> And what could upstream do to not rely on the .so files committed to their
> repos? Provide a list of aptitude install *-dev commands required for a
> developer?
>
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627362
>
> Best regards,
>
> Thomas Koch, http://www.koch.ro

As for finding dependencies on C libs automatically look at
dpkg-shlibdeps.

As for documenting them projects usualy give a list of packages they
depend on (e.g. needs gtk and asound) and under Debian the
debian/control file would contain a Build-Depends line listing the
specific packages needed to build under debian.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k46rw2it.fsf@frosties.localnet">http://lists.debian.org/87k46rw2it.fsf@frosties.localnet

How to manage/document C dependencies?
 

Le mercredi 23 novembre 2011 Ã* 10:15 +0100, Thomas Koch a écrit :
> But they also have a lot of dependencies to C libraries. These are currently
> still committed to their SVN as .so files.

Urrgh, that’s awful.

> I'm totally clueless about C. Is there any best practice for an upstream how
> to document your dependencies, their versions, license and download location
> in a central place, maybe even machine parsable?

The best way is certainly to use pkg-config. There are autoconf and
automake macros to easily tell your requirements and version information
about them, and in which objects you need them.

Download locations should be mentioned in the documentation, there is no
standard for that.

> And what could upstream do to not rely on the .so files committed to their
> repos? Provide a list of aptitude install *-dev commands required for a
> developer?

This is the kind of information that can also be mentioned in the
documentation; but in all cases it is pkg-config that should check they
are correctly installed.

Cheers,
--
.'`. Josselin Mouette
: :' :
`. `'
`-


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1322046570.20478.105.camel@pi0307572">http://lists.debian.org/1322046570.20478.105.camel@pi0307572

How to manage/document C dependencies?
 

On 11/23/2011 07:09 PM, Josselin Mouette wrote:
> Le mercredi 23 novembre 2011 Ã* 10:15 +0100, Thomas Koch a écrit :
>
>> But they also have a lot of dependencies to C libraries. These are currently
>> still committed to their SVN as .so files.
>>
> Urrgh, that’s awful.
>

This tells a lot about how horrible Jitsi is. To my experience, it is
supposed to have nice features (and it does, like ZRTP encryption,
which isn't seen often), but it crashes often. So much that it makes
it a totally unusable software. And I've tried it many times!!!

I don't want to force anything, and just want to voice my opinion
here. But ifit was up to me only, I'd say that this kind of software
should be kept out of Debian, for sanity reasons.

Just my 2 cents of opinion about Jitsi,

Thomas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4ECD0B16.1070708@debian.org">http://lists.debian.org/4ECD0B16.1070708@debian.org