policy on library packages

Michael Schwendt ms-nospam-0306 at arcor.de
Tue Mar 23 11:28:09 UTC 2004


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.

-- 





More information about the fedora-devel-list mailing list