|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Hi, there. Is there a sane, RPM-politically-correct way to replace one package with another which PROVIDES the same things?
I'm chewing on a rather obnoxious dependency-hell problem over in R-land, trying to incrementally approach automatic generation of RPMs to provide several thousand language-specific modules.
R has a different idea about what dependencies mean than most package managers do; If package 'foo' is going to successfully 'CHECK', the R package validation process, you need to have installed everything 'foo' Depends:, Suggests:, Enhances:, Imports:, and LinksTo:.
Anyone familiar with dependency maps can guess that this tree has many many tight loops, if you consider packages that "Enhance" each other. There are obviously many fewer of these problems if you limit yourself to true dependencies (e.g. Depends and Imports).
We'd really like to CHECK all the packages we put out in a repo; it's the upstream way to say a package has built correctly.. But of course we can't really do that.
One strategy I'm contemplating to do this is to build a package tree with a slightly munged namespace. So, say we're trying to build a pile of packages like
R-foo (enhances: R-baz ) R-bar (enhances: R-baz , depends: R-foo ) R-baz (enhances: R-bar ) This is an intractable problem. However, I could first make R-TEMP-foo ( Provides: R-foo ) R-TEMP-bar ( Provides: R-bar Depends: on R-foo, ) R-TEMP-baz ( Provides: R-baz )These wouldn't try to CHECK, they wouldn't be for distribution. But once they were installed, I could CHECK R-foo, because baz is already in place. Then, I could one at a time replace R-TEMP-[x] with R-[x].
But of course, I can't rpm -e R-TEMP-foo, installed package R-TEMP-bar depends on it. I can't "upgrade" R-TEMP-foo to R-foo...
So that's why I want to "replace" one package with another, which I'm morally certain will satisfy the dependency tree just as soon as I get it in place.
Should I just shrug and force it? Should I play games with version numbers? Some obnoxious prerelease nomenclature?
- Allen S. Rout _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list