Re: my package requires mysql OR MySQL, how do I state that in thespec file?

["Michael A. Peters" <mpeters mac com>]

On Fri, 2003-09-26 at 08:32, Jeff Johnson wrote:

> 
> However, a couple of the major problems with mapping as above are:
> 
>     1) Who/how/what/when/where for maintaining the mapping. Note no why ;-)

One possibility is to get freedesktop.org (or LSB) involved.
A "standard" for package naming, so to speak - and then it is up to the
distro to do the mapping if the naming is different - and this could be
done in the spec file with a Provides tag, specifying that package foo
provides bar.

With very few exceptions (such as XFree86) I prefer to name a package
after the tarball the source comes in. With gtk+2 that isn't the wisest
thing as an upgrade could remove the gtk+1 package.

But if the BuildRequires and the Requires specified a standard package
name, and distro's provided that standard package name - it would never
be an issue.

If MySQL is the standard name, but the distro prefers to name packages
on the tarball - then mysql could provide MySQL and there won't be
issues.

I think this would be the best way to do it.

I *sort of* do that already - I maintain spec files for a very small
custom distro, and if I am aware that a naming convention is different
in Red Hat or Mandrake, I'll try to put in a Provides just to make it
easier for a user to build a src.rpm from those distro's.

It would be easier if I could go to freedesktop.org and look up a
standard. I'm not too fond of LSB - they specify the package manager I
like but I don't think they should specify one, it gets in the way of
innovation with alternate package styles (like source based distro's).
They specify SysV init - and even what runlevels do what. We are
currently thinking of dumping SysV init because there are some cool
alternatives that are dependency based - and start things in parallel
when possible - cutting boot time dramatically.

freedesktop.org seems to stay away from "limiting" standards ...

> 
>     2) Adding content mapping adds enormous QA complexity. Many depsolvers
>     are routinely looking at dependencies from ~500 packages. Presto, 
> chango, now
>     do the same QA for all possible mapping substitutions. That's a very 
> hard problem.

Yes - you are right, which is it probably should be done in a way where
there is a standard name, and if your package is named differently, you
use a Provides. That way there is no mapping file.

If a standard name doesn't exist, then provide the name of the source
tarball (less the ver.tar.gz)