Question regarding RPM packaging of interactive software.

[Jon Ciesla]

--
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 at jcomserv.net> 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>