Proposal to reduce anti-bundling requirements

Neal Gompa ngompa13 at gmail.com
Thu Oct 8 05:02:32 UTC 2015


On Wed, Oct 7, 2015 at 8:33 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:

> Jared K. Smith wrote:
> > I think this strikes a fair balance between promoting packaging hygiene
> > and recognizing that not all upstream communities feel the same way
> Fedora
> > packagers do about bundled libraries.
>
> The thing is, it should NOT matter at all how upstream feels. If we treat
> unbundling as something to do with upstream, we already failed. Unbundling
> must be done whether upstream likes it or not, even in upstream's spite!
> And
> it's the packager's job to do it: "upstream does not support it" is NOT a
> valid excuse for not unbundling!
>
>         Kevin Kofler
>
>
​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.

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.

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.


-- 
真実はいつも一つ!/ Always, there's only one truth!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20151008/78e03b6a/attachment.html>


More information about the devel mailing list