Proposal to reduce anti-bundling requirements

[Kevin Kofler]

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.

        Kevin Kofler