Re: xine-lib plugins

[Greg Troxel <gdt%ir.bbn.com@localhost>]

David Holland <dholland-pkgtech%netbsd.org@localhost> writes:

> There are currently two plugins for xine-lib: xine-arts and
> xine-esound, which build the respective audio drivers.
>
> xine-lib is not set up to allow building drivers individually; these
> plugin packages work by configuring it with arts/esound and without X,
> then building more or less the whole package and installing just the
> one plugin file. This is tedious because it's a fair amount of wasted
> compilation; it's also problematic because the plugin ABI might or
> might not be invariant over those configuration changes and so the
> resulting drivers might or might not work properly with the main
> xine-lib package.
>
> There's also right now a problem that due to a combination of
> circumstances of the way things are set up, the plugin packages end up
> with a bogus dependence on libXv, and maybe other things (and I'm
> about to make this worse...)
>
> I'm thinking it would probably make sense to kill off xine-arts and
> xine-esound and instead compile in the support based on PKG_OPTIONS;
> this would be consistent with a number of other packages and would
> eliminate the problems.

I can see why you'd want to do that, but it can make binary packages
substantially less useful - what is the default?

There is a basic notion in pkgsrc, perhaps not adequately documented,
that split packages are preferred to options when one or more can
reasonably be added at runtime.  This is basically so that a binary
package collection can be used, but also allows those who have built foo
from source to add foo-bar without having to rebuild foo.

Options are necessary when the behavior of a component is changed, and
this is more likely when the upstream is more monolithic and less
plugin-ish.

As for plugin ABI changing, the plugin packages should depend on the
base package, with revision bumps as needed, so that's more or less a
solved problem.  Plus, I'd keep the version numbers in sync and update
them at the same time.

There are two proper fixes:

  upstream should add --disable/--enable options so that one can
  configure it for just the parts one wants, finding other dependent
  parts in PREFIX.  A nice example of this is GNU Radio.  Then the split
  packages can have the right dependencies and just build the desired
  parts.  I have proposed fixes like this, and found that many projects
  are not that excited about it, seemingly because they only care about
  Linux where split packages are built differently.

  pkgsrc could grow a way to build a package from source and then make
  several binary packages with sub-parts.  This seems to be the Linux
  way.  While this makes split binary packages, it also means that
  building from source will build too much.

In practice, there are two workarounds:

  patch Makefiles in each split package to make it be like
  --disable/--enable had been used.  See sysutils/amanda.  This is not
  pretty, and it's a lot of work.

  use options, and make the default be the way that the packager thinks
  it ought to be.  Works great if you agree with the packager, and if
  not you have either bloat or you have to build from source.


So all that said, I think it would be good to allow separate binary
packages of things that are already plugins.

I see your point about extra dependencies, but if plugin depends on base
and base depends on foo, then plugin depending on foo doesn't hurt much,
even if it's just there to make configure happy while checking for a
library it won't use.