On Thu, 2005-08-18 at 10:13 -0500, Lance Albertson wrote: > Mike Frysinger wrote: > > On Thursday 18 August 2005 10:28 am, Christian Parpart wrote: > > > >>Do we have a general accepted gentoo policy for this? > > > > > > general policy is to not split packages (and i agree with this ...) > > bind and bind-tools is split ;) Why is it so bad to split packages? (I'm > just curious) Seems a bit odd that we can't have a library only, client > only, etc package like the other distros. Of course, I understand that
Other distributions are also binary-only, so there's no real comparison here. While I think having "client" and "server" type USE-flags is really a bad idea, I don't see a problem with providing a library. I 100% disagree with splitting the package into client and server, but don't think it would be bad to have it like this: net-libs/libmysqlclient dev-db/mysql You'll notice that there is no server package. The dev-db mysql package should be the entire distribution. Splitting out a separate library for client-only shouldn't be too bad, but I still disagree with it, for the most part. > we could use useflags for that, but is that really the best solution for > this particular issue? Honestly, we shouldn't be splitting packages like this. If upstream has a "--clientonly" or "--libsonly" configure option, that would be one thing, but if they don't why should we split them up? All it does is increase the number of packages that would need to be updated for security bugs and increase complexity, along with tree size. We already complain about not enough manpower. Duplicating effort all over the tree just to remove a few binaries from a system isn't a valuable use of developer time, in my opinion. This is especially true as we have methods of masking things from being installed. > Oh well, I'm just a sysadmin, not a coder so I'll got back to my cave. ;) -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
