[Fedora-packaging] library dependency strawman (of doom?)

[Jan Chaloupka]

On 04/29/2015 08:10 PM, Matthew Miller wrote:
> On Wed, Apr 29, 2015 at 11:59:43AM -0500, Adam Miller wrote:
>> That's fair I suppose, I just think that the scenario is slightly
>> different because it's build time vs runtime deps for Go vs
>> Python/Ruby/Perl. At runtime that giant dep list disappears. Maybe I'm
>> over thinking this but it does seem different to me. However, I agree
>> that if we can deal with some pain upfront and have less later then
>> all the better. Just from a ground zero standpoint it seems like a lot
>> of churn.
> So, I'm not necessarily _proposing_ this, but something to think about:
> I have a suspicion that a long tail of dependencies actually aren't
> used by many multiple projects that get into Fedora, meaning that the
> upfront pain does not actually translate to this benefit in a large
> number of cases. (Of course, there are other benefits, including easier
> security tracking, but since this is a strawman let me just set that
> aside for a bit.)

I am hoping for better future of golang projects :) All packaged source 
codes are used only as build-time dependencies. Not for development (go 
get is used instead). Once the projects stabilize and stop breaking API 
and tools start using stable releases than the whole golang ecosystem 
will come to mind. For this sake all dependencies should be unbundled, 
packages updated and spec files polished. This way we can encounter with 
problems and solve them as time goes. At the same time tools for 
analysis and health care can be created. And so on.

>
> What if, instead of requiring separate, unbundled packaging of
> dependencies the first time they're required, they instead get
> documented somewhere. The _second_ time something needs the same thing,
> the packagers for both the first and second package work together to
> split out that dep into its own package. This a) defers the "payment"
> until closer to the point of "delivery" and b) means that the two
> packagers share the work. It would also mean fewer unloved packages
> which were created solely to fill a dep need — and maybe even orphaned
> if that need changes.
>