-- in your fear, seek only peace in your fear, speak only love -d. bowie On Sat, 8 Jan 2011, Jason L Tibbitts III wrote: >>>>>> "JC" == Jon Ciesla <limb@xxxxxxxxxxxx> writes: > > JC> I can't recall at the moment where this stems from, but the > JC> rationale, as I recall, was that we can never be sure if the > JC> database is available at RPM install/upgrade time. > > It's pretty simple. Creating databases isn't generally something that > an rpm can do on its own; for mysql, at least, rpm certainly won't have > any way at all to get at local administrative password. And of course > databases can be on remote machines, so such packages rarely have > dependencies on the actual database server anyway (just the client > libraries) and certainly no way to figure out where the remote server is > or how to access it. > Right, and on top of that, there are many applications that can use multiple types of database backends. Bacula, for example, can use MySQL, PostgreSQL, or sqlite. While finding out which it's using can be done by looking at the config files, do we really want to teach RPM to read hundreds of different types of config files? Plus the dependancies on client libs? > Now, sqlite would be a different matter. It would still be terribly > antisocial for a package to wipe out existing data on an upgrade, but > creating and managing sqlite databases is something that could be done > by the package (although I'd still think that's better left for > runtime). Agreed, theoretically possible, but inadvisable. > > - J< > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
