1 |
On Thursday 04 March 2010 19:07:22 Mick wrote: |
2 |
> > There will be a reason why mysql is being pulled in, most likely a |
3 |
> > package that must have it. |
4 |
> |
5 |
> If a package must have it, wouldn't the USE flag mysql switch to + ? |
6 |
|
7 |
Your post seems to indicate a lack of understanding of how these things work. |
8 |
|
9 |
Often-times things are not optional, that's what "must" means. USE is |
10 |
diametrically opposed to that as it has to imply a meaning of "may". If a |
11 |
package if hard-coded to use mysql, then it must have it, and putting it in |
12 |
USE in pointless. |
13 |
|
14 |
There's no rule about this. If mysql is a hard dep, then that's the way it is. |
15 |
|
16 |
> > If a user wants postgres, he should install and run postgres. How would |
17 |
> > this affect the presence or absence of mysql? |
18 |
> |
19 |
> Well, I am assuming that if postgres can do what mysql does, then it |
20 |
> could work in its place. Like if syslog-ng will do what metalog does, |
21 |
> then the virtual/log-thingie will not insist in pulling in metalog. |
22 |
> Anyway, the postgres is just an example of asking why are we locking |
23 |
> down the choice of a database to a particular package/provider. |
24 |
|
25 |
Again, you appear to fail to understand. metalog supports a variety of |
26 |
database backends. Not all apps are like this, some are hard-coded. If you |
27 |
want to use an app like this, you have no choice but to install mysql. |
28 |
|
29 |
If you don't like this, then your choices number two: |
30 |
|
31 |
1. Tough, get over it; |
32 |
2. Use a different app |
33 |
|
34 |
-- |
35 |
alan dot mckinnon at gmail dot com |