| 1 |
On Fri, Aug 19, 2005 at 05:30:42AM +0200, Christian Parpart wrote: |
| 2 |
> On Thursday 18 August 2005 17:44, Chris Gianelloni wrote: |
| 3 |
> > On Thu, 2005-08-18 at 10:17 -0500, Brian Harring wrote: |
| 4 |
> > > 2) ebuild maintenance will be a nightmare- every new version will |
| 5 |
> > > require again walking the source to see if the lines you've drawn for |
| 6 |
> > > dividing the source are still proper. |
| 7 |
> |
| 8 |
> minimize the duplication by a mysql eclass, just like we do for apache e.g. |
| 9 |
> (and lots of others) that prevent us from code duplication. |
| 10 |
|
| 11 |
Point was you would have to inspect each release to ensure it still |
| 12 |
fits. If upstream does this for you, it's not any more of an issue |
| 13 |
then normal QA. |
| 14 |
Yes this is being anal (re: the verification), but it's proper QA ultimately. |
| 15 |
|
| 16 |
> > I'd see no problem with this in mysql, if, for example, mysql's Makefile |
| 17 |
> > had a "make libmysqlclient" target. In that case, I would make it a |
| 18 |
> > separate package. |
| 19 |
> |
| 20 |
> Having a look at the already provided libmysqlclient ebuild [1] it obviousely |
| 21 |
> (and for our luck) looks like upstream supports this installation types. |
| 22 |
Multiple configure/builds required- also is worth verifying that |
| 23 |
building the client/server against the lib does just that, uses |
| 24 |
existing on disk lib rather then rebuilding. |
| 25 |
|
| 26 |
> Why? What package would depend on the server in particular? If the user wants |
| 27 |
> the server to be run on localhost, than he would just have to add it to his |
| 28 |
> emerge args as well. I see no problems there - instead: it would be a great |
| 29 |
> enheancement. (IMO) |
| 30 |
> |
| 31 |
> > All in all, I think it isn't worth even attempting at this time. |
| 32 |
> read above. do you still think so? If so, why? |
| 33 |
Increased configuration run time per upgrades, two packages two |
| 34 |
maintain; why is that an issue? |
| 35 |
1) dev-db/mysql must dep on the matching lib version. $PV address |
| 36 |
this, mostly. |
| 37 |
2) 2 packages to handle in p.mask and for doing keywording changes |
| 38 |
3) 2 packages to handle at the user side of things for |
| 39 |
keywording/masking. |
| 40 |
|
| 41 |
Real strong points I'm sure; key thing about all of this is that it's |
| 42 |
increased A) work, B) manual steps required (read: points of screwup). |
| 43 |
All of the args come down to that, extra complexity/work. |
| 44 |
|
| 45 |
If I saw mysql as being loosely bound between it's server and lib |
| 46 |
components, I'd think it was good to potential chunk into two |
| 47 |
packages. I don't, obviously. |
| 48 |
|
| 49 |
Use conditionals exist *exactly* for user choice like this (iow you've |
| 50 |
got the tools already to keep it contained as one). That's honestly |
| 51 |
the strongest arg I can make; the limiting factor is that you're |
| 52 |
stuck waiting since use dep's aren't available yet. |
| 53 |
~harring |
Archives