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.
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
