unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: Leo Famulari <leo@famulari.name>
Cc: 44806@debbugs.gnu.org
Subject: [bug#44806] [PATCH staging 5/6] gnu: Add pitivi.
Date: Wed, 16 Dec 2020 01:18:33 +0100	[thread overview]
Message-ID: <eafc96dd0cc3a7c91b3b537b92806049585492c5.camel@student.tugraz.at> (raw)
In-Reply-To: <X9krQA8RDMmOZaNg@jasmine.lan>

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	other threads:[~2020-12-16  0:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-22 20:34 [bug#44806] [PATCH staging 0/6] Add Pitivi Leo Prikler
2020-11-22 20:36 ` [bug#44806] [PATCH staging 1/6] gnu: libpeas: Update to 1.28.0 Leo Prikler
2020-11-22 20:36   ` [bug#44806] [PATCH staging 2/6] gnu: gst-editing-services: Build with introspection Leo Prikler
2020-12-15  7:17     ` Leo Famulari
2020-11-22 20:36   ` [bug#44806] [PATCH staging 3/6] gnu: Add gst-plugins/selection Leo Prikler
2020-12-15  7:19     ` Leo Famulari
2020-11-22 20:36   ` [bug#44806] [PATCH staging 4/6] gnu: Update and deprecate gst-transcoder Leo Prikler
2020-12-15  7:21     ` Leo Famulari
2020-12-15  8:45       ` Leo Prikler
2020-12-15 21:21         ` Leo Famulari
2020-11-22 20:36   ` [bug#44806] [PATCH staging 5/6] gnu: Add pitivi Leo Prikler
2020-12-15  7:25     ` Leo Famulari
2020-12-15  7:55       ` Leo Prikler
2020-12-15 21:31         ` Leo Famulari
2020-12-16  0:18           ` Leo Prikler [this message]
2020-12-29 18:28             ` Leo Prikler
2020-12-29 19:04               ` Leo Famulari
2020-12-29 19:27                 ` bug#44806: " Leo Prikler
2020-11-22 20:36   ` [bug#44806] [PATCH staging 6/6] gnu: ffmpeg-4.2: Remove rav1e from inputs Leo Prikler
2020-12-15  8:04     ` Leo Famulari
2020-12-15  7:16 ` [bug#44806] [PATCH staging 0/6] Add Pitivi Leo Famulari
2020-12-15  9:05   ` Leo Prikler
2020-12-15  9:03 ` [bug#44806] [PATCH v2 1/5] gnu: libpeas: Update to 1.28.0 Leo Prikler
2020-12-15  9:03   ` [bug#44806] [PATCH v2 2/5] gnu: gst-editing-services: Build with introspection Leo Prikler
2020-12-15  9:03   ` [bug#44806] [PATCH v2 3/5] gnu: Add gst-plugins/selection Leo Prikler
2020-12-15  9:03   ` [bug#44806] [PATCH v2 4/5] gnu: Update and deprecate gst-transcoder Leo Prikler
2020-12-15  9:03   ` [bug#44806] [PATCH v2 5/5] gnu: Add pitivi Leo Prikler
2020-12-15 21:20     ` Leo Famulari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eafc96dd0cc3a7c91b3b537b92806049585492c5.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=44806@debbugs.gnu.org \
    --cc=leo@famulari.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).