[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: One source, multiple packages?

Tom Lane wrote:
"Richard W.M. Jones" <rjones redhat com> writes:
On Fri, Feb 13, 2009 at 04:06:41PM -0600, King InuYasha wrote:
Why can't RPM packages have a Requires saying "mysql OR postgresql" or
something like that?

Debian has a mechanism exactly like this.

However it is my understanding (possibly incorrect) that the right way
to deal with this with RPM is using virtual provides, ie each database
would have this:

  Provides: database

Which allows any package that needs "a database" to require that.

I'm not exactly sure how requiring mysql or postgresql would work out
in reality, since they have quite different capabilities and SQL

Yeah, the SQL standard is lax enough in itself and then everybody has
their own little improvements :-(.  Sad to say, there is no chance worth
mentioning that a package that just "requires a database" will work with
all the flavors out there.  It generally takes nontrivial development
work to make it work with any given DB.  So the first form of this ---
eg, "this package can work with mysql, postgres, or sqlite" --- is the
only thing that would have a chance of succeeding.  Things might be a
shade better for other types of alternatives but I wouldn't bet on it.

			regards, tom lane

Very few things should require a database to begin with. Who's to say that I want to run the database on the same computer as the client app?

When you consider the exceptions to that rule, things are far less ambiguous. Mostly its tools, which are bound to one app anyway, or things that need a small local store for atypical things like RPM. Those people are usually bound to sqlite or db2.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]