Re: Allowing one package to virtually "provide" another

Tim Jackson wrote:

This question is related to the PEAR Installer in general, not to any existing or proposed packages on pear.php.net. Let's say I have an application package called "Foo". This package includes support for a "MySQL" database. Right now, I want to package "Foo" it as a single package. However, I'm aware that if in future I add support for other database backends, I might want to split Foo into subpackages, for example: Foo Foo_Driver_MySQL Foo_Driver_Postgres or whatever. Is there a way of doing this, such that if I split the package in future, a "pear upgrade" will transparently download Foo_Driver_MySQL to maintain the same set of functionality? I can't find anything in the package2.xml spec about this.

What about Foo new version would add a dependency on Foo_Driver_MySQL ? Ah no, name would change.

Over in RPM land, we have a tag in our specfiles (equivalent of package.xml) which is called "Provides" that does exactly this. For example: # First package ... Name: Foo Provides: Foo_MySQL ... # After split, first package: ... Name: Foo ... # After split, second package: ... Name: Foo_MySQL ... So previously you said

yum update Foo getting the whole What you say after the split ? still yum update Foo ? getting the whole ? Not sure about how you mean that. -- toggg