On Thursday 18 August 2005 17:44, Chris Gianelloni wrote: > On Thu, 2005-08-18 at 10:17 -0500, Brian Harring wrote: > > 2) ebuild maintenance will be a nightmare- every new version will > > require again walking the source to see if the lines you've drawn for > > dividing the source are still proper.
minimize the duplication by a mysql eclass, just like we do for apache e.g. (and lots of others) that prevent us from code duplication. > I'd see no problem with this in mysql, if, for example, mysql's Makefile > had a "make libmysqlclient" target. In that case, I would make it a > separate package. Having a look at the already provided libmysqlclient ebuild [1] it obviousely (and for our luck) looks like upstream supports this installation types. > This would also mean a lot of work on your part, as > every single package that had a dependency on mysql would now need some > way of specifying whether the server was going to be local or remote, to > properly *DEPEND on the correct package. We've plenty of tools that help us in searching for all ebuilds *directly* depending on "dev-db/mysql"; than you just need to decide, wether this needs the server or not. And (w/o looking at them) I do predict, that 100% of them will only need libmysqlclient. Why? What package would depend on the server in particular? If the user wants the server to be run on localhost, than he would just have to add it to his emerge args as well. I see no problems there - instead: it would be a great enheancement. (IMO) > All in all, I think it isn't worth even attempting at this time. read above. do you still think so? If so, why? Regards, Christian Parpart. [1] http://bugs.gentoo.org/attachment.cgi?id=55816 -- 04:43:52 up 148 days, 17:51, 1 user, load average: 0.66, 0.76, 1.15
pgpojzr28kw9N.pgp
Description: PGP signature
