guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#44806] [PATCH staging 5/6] gnu: Add pitivi.


From: Leo Prikler
Subject: [bug#44806] [PATCH staging 5/6] gnu: Add pitivi.
Date: Wed, 16 Dec 2020 01:18:33 +0100
User-agent: Evolution 3.34.2

Am Dienstag, den 15.12.2020, 16:31 -0500 schrieb Leo Famulari:
> On Tue, Dec 15, 2020 at 08:55:17AM +0100, Leo Prikler wrote:
> > Am Dienstag, den 15.12.2020, 02:25 -0500 schrieb Leo Famulari:
> > > Do we do this to save space? Or to avoid the rest of the bad
> > > plugins?
> > Both would be valid reasons to do this imo.  Adding more bad
> > plugins is
> > likely also not going to increase the number of features Pitivi
> > offers.
> 
> This is a good idea for the "bad" plugins, because they are rarely
> used
> in Guix, so there is less chance of unecessary duplication compared
> to
> the other collections of GStreamer plugins.
There is sadly still a lot of duplication between a plugin "selection"
and its base package, so the option will have to be used sparingly. 
The reason why I opted for writing a procedure, that redoes the whole
build rather than just copying some shared libraries, is because I
don't think the latter would be particularly safe to do.  Perhaps I'm
wrong on that, however.

> Still, it increases complexity, and it sholud be "worth it" in some
> sense. If gst-plugins/selection becomes popular, it may be that the
> increase in package objects outweighs the disk space savings — the
> package graph may grow so large that it slows Guix package operations
> down too much. The disk space savings may be obviated in that case,
> anyways.
I think it's only "worth it" when importing not more than two or three
plugins from "bad" or "ugly".  Even then the savings are only moderate,
as gstreamer will still build what it deems to be absolutely necessary.

To be completely honest, I also don't expect this to be around for too
long.  I am more than happy to see this procedure vanish at some point
when we have parameters, though maybe that'd be a very Gentoo-y way of
using parameters and still suffer from the same problem.

> If you choose to apply for commit access, as I suggested, you will be
> able to use your judgement here :)
Sounds like it slowly gets time to take this serious and apply for
commit access, then.  I'll try to get that done soon-ish™.

Regards,
Leo






reply via email to

[Prev in Thread] Current Thread [Next in Thread]