vlc/vlc-nox distinction

[Sebastian Ramacher]

On 2014-08-19 07:46:02, Reinhard Tartler wrote:
> On Mon, Aug 18, 2014 at 8:13 PM, Sebastian Ramacher
> <sramacher at debian.org> wrote:
> > (Dropping J-B from CC. I think this is purely Debian related now.)
> >
> > On 2014-08-18 22:37:42, Sebastian Ramacher wrote:
> >> On 2014-08-17 23:22:02, Jean-Baptiste Kempf wrote:
> >> > On 16 Aug, Reinhard Tartler wrote :
> >> > > I believe that upstream doesn't care that much about this, because
> >> >
> >> > I remember the idea.
> >> >
> >> > Basically, the idea was to split so that servers using VLC to do
> >> > streaming wouldn't need libX11 and all the rest.
> >> >
> >> > > otherwise I'd expect the Makefiles to be a bit more helpful with
> >> > > determining this. J-B, I'd like you to confirm if I'm right here.
> >> >
> >> > This idea indeed failed, because libavcodec, one of the main codec
> >> > library, can depend on vdpau/vaapi, and both of those acceleration
> >> > libraries thought it was cool to use libX11...
> >> > Therefore, a vlc-noX wouldn't have avcodec plugin...
> >> >
> >> > Some other distributions split the VLC free-stack (Xiph formats)
> >> > from the rest, for patent reasons.
> >> >
> >> > For 3rd party programs using libvlc, an idea was to do a vlc-plugins
> >> > splitted from vlc, so that they don't get libQt in.
> >> > So, something like:
> >> >  - libvlccore
> >> >  - libvlc
> >> >  - vlc-core-plugins
> >> >  - vlc
> >>
> >> I'll see if I can come up with something here and prototype a possible
> >> split. As soon as I've got something, I'll post a link to a branch.
> >
> > I've pushed a work-in-progress feature/vlc-plugins branch [1]. vlc-nox
> > has been left alive. Looking at the popcon data there seems to be
> > interest in the package (vlc: 51349 installs vs. vlc-nox: 53687
> > installs).
> 
> The problem I initially experienced was how to come up with commits
> such as http://anonscm.debian.org/cgit/pkg-multimedia/vlc.git/commit/?h=feature/vlc-plugins&id=3909306d196dff05726cf3c800fa62bf2f8e7ad8
> without spending hours trying to figure out what renames, additions
> and removals of vlc plugins happend upstream. I started with a hit and
> miss, but after 5 recompilations of VLC *sic* I got tired of failing
> builds at package assembly time and started to grep and diff
> buildlogs. I am therefore wondering if that effort is really worth the
> trouble. I seems that you think it is. OK. Maybe I can come up with
> scripts to grep  the build logs to streamline this process.
>
> ...
>
> The only piece that I'm missing is what Fabian mentioned: A more
> declarative way to describe what plugin goes to vlc-nox and what to
> vlc. See above.

Yes, that part is really annoying. Thinking about it a little bit more, a script
would be doable. I'll implement something that

 1. correctly installs the plugins into vlc and vlc-nox respecting their dependencies
 2. takes a list of plugins that we want to have specifically in vlc (like the
     visulization plugins).

I'd like to postpone that until a -3 upload.

> >  - Killed vlc-plugin-pulse and moved the PulseAudio plugins to vlc.
> >    Xfce, KDE and Gnome all pull in libpulse0 anyway, so I think there is
> >    no need for the split.
> 
> I don't have a strong opinion on this. I feel that users might
> complain, but we can surely wait for those bug reports to happen (if
> they happen)

In the worst case I'll revert it. But given that vlc depends on libpulse0 (via
libsdl1.2debian) even without intalling vlc-plugin-pulse, I doubt there will be
many complaints (I might be wrong of course).

> Given that vlc is currently in NEW anyway, I guess uploading to
> unstable as 2.2.0~pre2-2 would hurt.

As clarified on IRC, this should haven "wouldn't hurt". I'll upload -2 tonight.

Cheers
-- 
Sebastian Ramacher
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20140819/50f34735/attachment.sig>