QA: bundled libraries

Where bugs go to lie down and rest

Moderator: Moderator

Post Reply
Posts: 16
Joined: Thu Aug 29, 2013 2:00 pm

QA: bundled libraries

#1 Post by hasufell »

tome4 bundles a lot of libraries such as bzip2, zlib, luajit2, expat, physfs and more. There is no explicit information on what exact versions those are or if they are modified and if so which changes have been made. Everyone has to figure that out by himself which is also a problem security-wise.
The minimum should be to ship patches against the vanilla libs with the tarball, saying exactly which version/commit was used and describing what each patch does.

On the other hand, it's better to just not bundle anything, because:
a) security: bundled libraries are somehow out of the scope of packagers. As an example: zlib had many severe vulnerabilities and if packages bundle copies of zlib, then every single one of it needs to be fixed _manually_. If packages link to it, distributors just fix up the system lib and are done.
These things are difficult to track and will cause security issues on the long run, cause developers/packagers and users might not even be aware that they are affected.
b) maintenance: for you and for any maintainer/packager. You modify libs, everyone has to track down security issues, QA issues, build time issues and plain bugs not just for the system lib, but also for every modified copy in every possible package. This happens regularly with Irrlicht or premake or lua which are often bundled. People also have to report bugs in several places instead of one, because they cannot be sure if you merge fixes regularly from upstream.
c) support: experience shows that people who bundle stuff don't accept bug reports for their bundled libraries although they might have modified them heavily (popular example is freeorion which "forked" gigi, but does not support it at all). Take it up with upstream they say. When you do it, upstream will tell you: erm, we don't support random forks. Maybe your version even introduces new bugs. No one will be responsible. This decreases support.
d) size: increased size, both in memory and on the disk, obvious
e) breakage: it happens from time to time that some packagers carelessly unbundle libraries without contacting upstream first and thus (partly) breaking the application for the end-user (this happened with supertuxkart on some distros afair). This is also partly upstreams fault, especially when there is no information on the modifications thus indicating that it is just bundled for convenience.

Why should you care about packagers? Well, they deliver your software to the end user and make it more known, so there are more people who use, test and report bugs for your software. That increases quality and maybe even code contribution.

You should also consider to make development OPEN... as in, use a public git repository and a bugtracker. Forums are inadequate. Publishing the source code does not mean development is actually open.

Post Reply