Re: xine-lib plugins

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Mon, Jul 21, 2008 at 09:51:21AM -0400, Greg Troxel wrote:
 > 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.

Right. But it also depends on it working correctly, and I don't think
what we've got in this case is necessarily a good idea. Nor would it
scale to all the random plugin libraries the package is capable of
generating.

 >   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.

I think the ideal here would be for each PKG_OPTION to generate a
sub-package. That way you get complete control both ways.

This would be pretty easy to do with xine-lib, if the framework
existed. I dunno if enough other packages with options are suitably
architected inside to make it worth pursuing.

But if so I think it would make a pretty nice framework for using
options and binary packages...

 > 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.

This is true.

I think for the time being the best solution is to leave it alone,
and worry about the config issues when and if it ever breaks.

-- 
David A. Holland
dholland%netbsd.org@localhost