[pkg-kde-talk] Re: kdelibs4c2a <-> kdelibs-bin circular dependency - advice requested

[Brian Nelson]

Adeodato Simó <dato at net.com.org.es> writes:

> * Christopher Martin [Wed, 18 Jan 2006 12:42:27 -0500]:
>
>> Yes, that would work. But I view this as more complex than necessary. Given 
>> the answers to 1), 2) and 3), I view merging kdelibs-bin into kdelibs4c2a 
>> as simpler, and involving virtually no work on the part of 3rd party 
>> maintainers (only a handful of packages depend on kdelibs-bin directly, and 
>> the new kdelibs4c2a can Provide: kdelibs-bin).
>
>> Since the separation between kdelibs-bin and kdelibs4c2a is not functional 
>> (i.e. they are always used together) keeping them apart seems unnecessary, 
>> and (as far as I can tell) only satisfies the notion that libraries and 
>> programs should be separate, even when, in this case, they are not used 
>> separately. But if people view my solution as too radical, then your 
>> proposal seems OK at first consideration.
>
>   Weeell, it'd be an option, but then we have this liiittle section from
>   Policy:
>
>   8.2. Run-time support programs
>   ------------------------------
>
>      If your package has some run-time support programs which use the
>      shared library you must not put them in the shared library package.
>      If you do that then you won't be able to install several versions of
>      the shared library without getting filename clashes.
>
>      Instead, either create another package for the runtime binaries (this
>      package might typically be named `<libraryname>-runtime'; note the
>      absence of the <soversion> in the package name), or if the development
>      package is small, include them in there.
>
>   Note the "must not"...

I think that's a stupid requirement in policy (and means the Qt4
packages violate policy).  kdelibs don't coexist nicely anyway AFAIK, so
the rationale for that requirement doesn't apply.

-- 
Captain Logic is not steering this tugboat.