Francesco Pedrini wrote:
> After the inspection of the new code and the discover of the new library
> I have a problem with the design of the new package structure, because
> if I follow the splitting scheme written above I'll have:
>
> kmobiletools - the real application;
> libkmobiletools - t
On Tue, 22 Aug 2006 09:17:50 +0200, Benjamin Mesing <[EMAIL PROTECTED]> said:
> According to Policy, Chapter 8.1 "the run-time shared library needs to
> be placed in a package whose name changes whenever the shared object
> version changes". You might need to do that, though I am not sure if
> thi
On Tuesday 22 August 2006 12:28, Bas Wijnen wrote:
> It's even better. If a library is not meant (by the Debian
> maintainer, who usually follows upstream) to be used by any other
> package, then it may be installed in the binary package which uses
> it.
The new library was implemented in order
On Tue, Aug 22, 2006 at 09:17:50AM +0200, Benjamin Mesing wrote:
> According to Policy, Chapter 8.1 "the run-time shared library needs to
> be placed in a package whose name changes whenever the shared object
> version changes". You might need to do that, though I am not sure if
> this statement is
Hello,
> > Either way, I don't think that's too much splitting, but you could
> > eliminate one library by mergeing the packages for libkmobiletools_at
> > and libkmobiletools together.
>
> Ok, then I will have:
>
> kmobiletools
> libkmobiletools
> libkmobiletools-dev
> and kmobiletools-plug
Francesco Pedrini <[EMAIL PROTECTED]> wrote:
> Ok, then I will have:
>
> kmobiletools
> libkmobiletools
> libkmobiletools-dev
> and kmobiletools-plugin-kontact.
>
> It seems fine, I can always split the phone engines in a separated
> package when the GAMMU engine (and maybe others) will be added
On Tuesday 22 August 2006 02:09, Tyler MacDonald wrote:
>
> Can kmobliletools-plugin-kontact (or anything else out there based
> on libkmobiletools) operate independantly of the main application? If
> not, the only split might need to be the kontact plugin vs.
> kmobiletools, to avoid kmobile
Francesco Pedrini <[EMAIL PROTECTED]> wrote:
> After the inspection of the new code and the discover of the new library
> I have a problem with the design of the new package structure, because
> if I follow the splitting scheme written above I'll have:
>
> kmobiletools - the real application;
>
8 matches
Mail list logo
