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)