Proposal to reduce anti-bundling requirements
kevin.kofler at chello.at
Thu Oct 8 22:58:05 UTC 2015
Matthew Miller wrote:
> In many cases, this effectively means creating a Fedora-specfic fork of
> the project.
Only if you call patches to the build system (with little to no changes to
the actual code) a "fork".
> Even if we accept unbundling as goal in itself is a given, there just
> aren't enough people in the world who have the inclination, time, and
> expertise to do this. Especially when you consider that for most projects,
> the only people with *deep* understanding of this kind of invasive change
> *are* the upstream.
Huh? 3 simple steps to unbundling (>90% success rate, especially with the
growing number of stupid upstreams that bundle not out of necessity, but
because they simply don't believe in unbundling):
1. rm -rf the bundled library (in %prep, or rip it out of the tarball
entirely if there is any chance of a licensing issue of any kind),
2. Remove the building of the bundled library from the build system and add
the required -I and -l flags instead.
3. Check the source code for hardcoded relative
#include "../3rdparty/foo/bar.h" paths and fix them to use proper
#include <bar.h> or #include <foo/bar.h> paths (depending on the library,
read its documentation). (If the code already uses the correct path
style, there is nothing to do.)
> So, in practice, assuming inclination, time, and *just enough* expertise,
> what we risk is a debundled package with new, unique bugs
Then they get reported and we can look into fixing them. If we just ship the
bundled library, the problem will never get fixed properly.
> possibly with security implications of their own.
Do you have any concrete examples where unbundling libraries caused security
issues? To me, this looks like a very abstract threat, and in no way
comparable to the major security risk posed by outdated bundled libraries.
> That's not getting us closer to the goal, even if it feels like it's a
> rule that *ought* to.
It is, see above.
> There are people with inclination and expertise, but not time. The new
> rules will help with that; their time and expertise can be focused
> where it has the most meaningful impact,
Unbundling always has a meaningful impact on ANY package. Focusing it just
on some will not address the problem.
> which might actually be on automated tooling rather than debundling.
What kind of automated tooling? The only kind of tooling I can think of is
tooling to automatically upgrade bundled libraries, but then you end up
causing exactly the same "new, unique bugs" as when just using the system
library (or conversely, if it works just fine, just using the system library
would work just as fine!), without the other advantages of unbundling (disk
space, RAM and update download bandwidth savings).
No amount of tooling can replace unbundling.
More information about the devel