Allowing one package to virtually "provide" another

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.

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
...

Thanks

Tim

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

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

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

bertrand Gugger wrote:

>> 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.

You could do this, but it would defeat the object of
splitting it into a 
sub-package, because all users would still get BOTH parts.
What you want 
is that after it has been split into a sub package, new
users only get 
the "base" package if they install
"Foo".

>> # 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 ?

Well, just a general "yum update", assuming that
the version of "Foo" 
has been increased. I'm not sure offhand what would happen
if you just 
did a "yum update Foo" - it might work, or might
not.

Tim

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

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

Hi Tim,

Yes, use <subpackage> instead of <package>
dependency. so Foo depends on
Foo_Driver_MySQL.  If you want the option of not installing
all drivers,
use a dependency <group> named "default"
containing the Foo_Driver_*
that were present in the original package.

Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php