Neal Gompa wrote:
Not that I don't agree that we should pursue unbundling
whenever
possible, but I don't remember any contract or terms that explicitly said
*packagers* do the work of *developers* to re-architect
applications/services/etc to do stuff like that. In fact, I thought *the
whole point* of RPM packaging (and indeed packaging in general) was to
make it so that you could reliably build and install software. Spiting
upstream is just asking for trouble, too.
The whole point of a distribution is to ship a well-integrated set of
packages, not a bunch of isolated sandboxes that don't talk to each other.
If we ship the latter, we become entirely redundant and provide no service
whatsoever to our users.
I consider unbundling to be about integration, not development. In most
cases, you will be making little to no changes to the application's actual
code, just fix its broken build system.
Personally, I would consider "upstream does not support it"
a very valid
reason to not unbundle. It gets very hard to pin down where the problems
are caused when the rug is pulled out from under you. Some applications do
all kinds of things with their libraries or code chunks to make it safe or
useful for their needs.
As I said, either fix the application to work with the library or fix the
library to work with the application (and we need to force our library
maintainers to be more flexible when it comes to the latter – there too,
shipping an integrated set of packages is more important than blindly
following upstream's wishes).
We should, of course, default to unbundling. But if it's not
feasible, we
need a firm policy on how to include the software and continually engage
on developing solutions that are appealing to everyone on improving the
modularity of software and usefulness of reusing system copies of
libraries.
It is almost always feasible. The new policy just encourages packagers to
not even try!
Kevin Kofler