[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: xine-lib plugins
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
> 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
Main Index |
Thread Index |