On Tue, 23 Mar 2004 11:07:02 +0100, Aurelien Bompard wrote:
> I can't find the policy regarding library (sub-)packages. I am packaging a
> digital camera program for KDE called DigiKam (#1404). This package can use
> a plugins package for more features: digikamplugins (#1406). Thus,
> digikamplugins depends on libdigikam.so. But then, an image viewer for KDE
> called ShowImg (#1410) can also use digikam's plugins.
^^^
"can" as in "it's optional"? or "can" as in "there's a strict dependence
on a digikam library when digikam plugins support is built into the image
viewer"?
> In the end, we have
> an image viewer depending on a digital camera manager.
So, the dependence is automatic (due to a linked library)?
Is size a matter here? ;)
> This could be fixed
> by splitting libdigikam out of the main package, but it looks like it is
> rarely done in the Fedora distribution.
e.g.
$ rpm -qR kdeaddons | grep xmms
libxmms.so.1
$ rpm --redhatprovides libxmms.so.1
xmms-1.2.10-1.p
See also the recent discussion of FLAC, which was not split into
flac and flac-lib in Fedora Core 2 devel unlike fedora.us.
> Is there a policy regarding this
> kind of situation (I'm sure it is neither the only nor the fist time this
> happens) ? Is there a general policy as regards to sub-packages, and to
> library packages ?
IMHO, such changes should be implemented correctly upstream. A clean
modules system which allows adding/removing features at run-time. However,
if upstream is focused on source tarballs as opposed to distributions,
they likely not see a problem and expect everyone to build from source and
link in only the features that are wanted.
--
