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

* gnu/packages/video.scm (pitivi): New variable.
---
 gnu/packages/video.scm | 67 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)

On Sun, Nov 22, 2020 at 09:36:24PM +0100, Leo Prikler wrote:
> * gnu/packages/video.scm (pitivi): New variable.

Overall LGTM.

> +        ("gst-plugins-bad"
> +         ,(gst-plugins/selection gst-plugins-bad
> +                                 #:plugins '("debugutils" "transcoder")
> +                                 #:configure-flags '("-Dintrospection=enabled")))

> +                  ;; We've only added inputs for what Pitivi deems either
> +                  ;; necessary or optional.  Let the user's packages take
> +                  ;; precedence in case they have e.g. the full gst-plugins-bad.
> +                  `("GST_PLUGIN_SYSTEM_PATH" suffix
> +                    (,(getenv "GST_PLUGIN_SYSTEM_PATH")))))

Do we do this to save space? Or to avoid the rest of the bad plugins?

Am Dienstag, den 15.12.2020, 02:25 -0500 schrieb Leo Famulari:
> On Sun, Nov 22, 2020 at 09:36:24PM +0100, Leo Prikler wrote:
> > * gnu/packages/video.scm (pitivi): New variable.
> 
> Overall LGTM.
> 
> > +        ("gst-plugins-bad"
> > +         ,(gst-plugins/selection gst-plugins-bad
> > +                                 #:plugins '("debugutils"
> > "transcoder")
> > +                                 #:configure-flags '("-
> > Dintrospection=enabled")))
> > +                  ;; We've only added inputs for what Pitivi deems
> > either
> > +                  ;; necessary or optional.  Let the user's
> > packages take
> > +                  ;; precedence in case they have e.g. the full
> > gst-plugins-bad.
> > +                  `("GST_PLUGIN_SYSTEM_PATH" suffix
> > +                    (,(getenv "GST_PLUGIN_SYSTEM_PATH")))))
> 
> 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.

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.

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.

If you choose to apply for commit access, as I suggested, you will be
able to use your judgement here :)

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

Hello,

Am Mittwoch, den 16.12.2020, 01:18 +0100 schrieb Leo Prikler:
> Am Dienstag, den 15.12.2020, 16:31 -0500 schrieb Leo Famulari:
> > 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
Now that I do have commit access, is there anything still blocking
this?  I don't want to push a controversial change too quickly 🙂.

Regards,
Leo

On Tue, Dec 29, 2020 at 07:28:40PM +0100, Leo Prikler wrote:
> Hello,
> 
> Am Mittwoch, den 16.12.2020, 01:18 +0100 schrieb Leo Prikler:
> > Am Dienstag, den 15.12.2020, 16:31 -0500 schrieb Leo Famulari:
> > > 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
> Now that I do have commit access, is there anything still blocking
> this?  I don't want to push a controversial change too quickly 🙂.

Go for it!

My take on the conversation is that it's worth it for gst-plugins-bad,
which is rarely used.

I'm looking forward to `guix install pitivi`

Am Dienstag, den 29.12.2020, 14:04 -0500 schrieb Leo Famulari:
> On Tue, Dec 29, 2020 at 07:28:40PM +0100, Leo Prikler wrote:
> > Hello,
> > 
> > Am Mittwoch, den 16.12.2020, 01:18 +0100 schrieb Leo Prikler:
> > > Am Dienstag, den 15.12.2020, 16:31 -0500 schrieb Leo Famulari:
> > > > 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
> > Now that I do have commit access, is there anything still blocking
> > this?  I don't want to push a controversial change too quickly 🙂.
> 
> Go for it!
> 
> My take on the conversation is that it's worth it for gst-plugins-
> bad,
> which is rarely used.
> 
> I'm looking forward to `guix install pitivi`
Now pushed as c412900d3e8c59ad59c994fd65634f9aafae1800.