One source, multiple packages?

[Casey Dahlin]

Tom Lane wrote:
> "Richard W.M. Jones" <rjones at 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
>> syntax.
>>     
>
> 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.

--CJD