Development only package?

Toshio Kuratomi a.badger at
Fri Jul 8 20:04:36 UTC 2011

On Fri, Jul 08, 2011 at 01:50:34PM -0400, Orcan Ogetbil wrote:
> What about the case where the upstream tarball is not directly capable
> of generating a dynamic or static library?
This would not be a guarantee that it is okay to bundle the library.  It
would be one indicator but not the most important one.

> This is the situation for a review that I am doing [1]. vmpk bundles
> the rtmidi [2], but rtmidi is not available as an independent library.
> It consists of 1 source and 2 header files and is designed to be
> bundled in other software. Is it okay to bundle rtmidi in our vmpk
> package?
You're definitely getting into a grey area here and may well want to submit
this case to the FPC for an exception.  Process and standard questions to
answer here:

In general, if the library is being distributed as a separate upstream, you
can err on the side of making it available as a library and the packaging
guidelines will be happy but to bundle it you'll have to show that there's
a good reason for that.  The idea is that as the "library" upstream releases
new code the apps need to be kept up-to-date with that new code.  Sometimes
this is because the library is making security fixes which means that we
have to update.  Sometimes it's because some API is changing incompatibly
and the library upstream is not going to put any maintainance effort into
the old API.  The latter can tempt upstream apps to bundle the library.  But
unless they simultaneously commit to maintaining their fork of the code in
case of the former problems, we end up being on the hook to audit and
produce security fixes for the bundled libraries at a later date.

If the software is designed to be bundled into other software and modified
by those consuming the code (with appropriate records of that on upstream
websites, etc) then the FPC may grant an exception but we will have an
easier time granting an exception if it can be shown that the application
doing the bundling recognizes that they're assuming the burden of fixing the
bundled library, are capable of making security fixes to the bundled
library and understand the gravity of what they're doing.  In many cases,
upstreams only look at the short term cost savings of being able to take
someone else's implementation of something into their code base without
thinking about the long term cost of maintaining that foreign code into the

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : 

More information about the devel mailing list