On Fri, 2017-10-20 at 22:16 +0200, Michael Biebl wrote:
> On Thu, 19 Oct 2017 22:35:33 -0300 Daniel Serpell
> <[email protected]> wrote:
> > Package: gstreamer1.0-plugins-bad
> > Version: 1.12.3-2
> > Followup-For: Bug #862024
> > 
> > Hi!
> > 
> > Biggest culprit are the new opencv packages, there libopencv-contrib3.2
> > pulls libvtk (150MB) and other big packages, about 236MB in total.
> > 
> > Next in the list is libopencv-calib3d3.2, at 60MB,
> > libopencv-objdetect3.2 at 58MB, libopencv-imgcodecs3.2 at 57MB.
> > 
> > So, simply splitting /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstopencv.so
> > out in another package will reduce the size of dependencies to the
> > previous level.
> 
> Sebastian what do you think about splitting out less common used plugins
> with heavy dependencies into a separate binary package like
> gstreamer1.0-plugins-bad-extra?
> 
> The first plugin moved to this -extra package would be libgstopencv.so
> and we could move more plugins as we see fit (that's why I think using a
> rather generic name like -extra would be preferrable).
> 
> The main gstreamer1.0-plugins-bad package would have a suggests:
> gstreamer1.0-plugins-bad-extra

I'm fine with the idea, the main problem is that whatever I decide for
"extra" plugins, for someone it will be a important one :)

Moving opencv to its own binary package was on my list already, its
dependency chain is just too huge and most people don't need it.


So let's go with an "extra" package instead, I'll spend some time
thinking about what else would make sense to have moved. DirectFB
probably.

> A middle ground would be to investigate why  gstreamer1.0-plugins-bad
> needs libopencv-contrib3.2 with opencv and if this could be avoided.
> [...]

Yes, we use some of the contrib stuff unfortunately.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to