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: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions 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 future. -Toshio
Attachment:
pgpJrY7OefafR.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
