Re: Including .so symlinks in non-dev package: policy violation?
- To: firstname.lastname@example.org
- Subject: Re: Including .so symlinks in non-dev package: policy violation?
- From: Justin Pryzby <email@example.com>
- Date: Fri, 24 Mar 2006 10:07:36 -0500
- Message-id: <20060324150736.GA16961@andromeda>
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com> <firstname.lastname@example.org>
On Fri, Mar 24, 2006 at 05:00:19PM +0200, Fabian Fagerholm wrote:
> On Fri, 2006-03-24 at 16:34 +0200, Fabian Fagerholm wrote:
> > The plugin .so's are not designed to be accessed directly. The purpose
> > is to access them through libsynfig, which is properly versioned. In a
> > sense, they differ from shared libraries ("libraries that are to be
> > shared between applications").
> > Is it ok to include the unversioned symlinks for the plugin .so's in the
> > non-dev package (libsynfig0)?
> I forgot to mention that the plugins are shipped
> in /usr/lib/synfig/modules -- so the whole thing looks very much like
> the run-time support programs in policy 8.2, except in this case, the
> artifacts are shared objects, not executables.
Do you actually have to ship them as separate objects, or could you
conceivably link statically to them?
This is what Steve suggested here: