Elan Ruusamäe <[EMAIL PROTECTED]> [13-11-2005 17:07]: > On Sunday 13 November 2005 15:42, Radoslaw Zielinski wrote: >>> but in real life R: webserver = apache is also pointless, as if package >>> really is both apache compatible then it needs apache >= 1.3.33-3, >>> because earlier apache1 didn't have conf.d like support. >> Well, IMHO better this than nothing. Adding some kind of complicated >> P:/R: would make an overkill -- this kind of problem can be solved with >> poldek --upgrade-dist. > R: apache >= 1.3.33-3 is no more complicated than R: webserver = apache, just > use BuildRequires.txt as guide (or appropriate template.spec files)
IIRC I have removed P: apache from apache1.spec... IMO providing an existant package name (and using it as virtual dependency) is a *bad thing*. "R: webserver = apache" should be used when needed. > but the upgrade dist will not help with your offer, because poldek/rpm build > install older depending on requires lines. and without proper requires it > could happen that package is installed (upgraded) earlier than apache that > provides the functionality it needs. this leads to mess which average user is > not capable of resolving manually. i don't think it's worth of that. >> "Conflicts: apache1 < 1.3.33-3" in appropriate specs should do, but I >> don't think it's really needed. > if it's *requirement* then there should be requires line :) R: webserver = apache C: apache1 < ... > to sum this up, i think 'Provides: webserver = apache' has no value, and > only 'Provides: webserver' should be used, otherwise use Requires: apache "= apache" doesn't hurt, and I've added it for a reason (something required apache, but both versions were OK). R: apache, meaning apache1 or apache2, should be shot dead and buried. Of course, if an application requires *any* HTTP server, just "R: webserver" should be used. Not that many of our specs are prepared for it, but that's another story. -- Radosław Zieliński <[EMAIL PROTECTED]>
pgpowQPygKC9F.pgp
Description: PGP signature
_______________________________________________ pld-devel-en mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
