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.
--