[pkg-php-pear] [Pkg-php-pear] On PEAR packaging
wrobel at horde.org
Sat Jul 23 21:44:22 UTC 2011
Quoting Mathieu Parent <math.parent at gmail.com>:
> Hi Gunnar,
> 2011/7/7 Gunnar Wrobel <wrobel at horde.org>:
>>> I have uploaded version 0.1 of the package to unstable (it should pass
>>> NEW first, but this seems fast those days: thanks to the ftp team).
> I have uploaded a new version, but it has some problems (fixed in
> current git). I will upload version 0.3 soon.
>>> Still TODO, on the pkg-php-tools package:
>>> - (maybe) change the algorithm to name packages?
>> If possible yes. The short name of a PEAR channel can be identified by
>> looking at the channel.xml - see "suggestedalias" in
> (following discussion on IRC)
> sathieu: I have thought of your proposal to construct the deb pkg name
> using the pear channel.
> sathieu: This is not possible in all cases, as the channel is not
> necessarily subscribed at build time
> sathieu: so, we have to construct the deb pkg name from two parameters
> only: pear package name and channel url
> sathieu: also, there is not way to define if it is a app or not from
> those two params.
> wrobel: probably hard to get a generic, reasonable scheme out of
> those two :-)
> Attached is the current proposed algorithm (pearname2dpkgname).
> It will handle the most common cases (see
> http://pear.php.net/channels/ for a list of channels) but not some
> corner cases that will probably not be used within Debian.
> Some outputs:
> $ ./pkg2pkg Net_SMTP pear.php.net
> $ ./pkg2pkg PEAR pear.php.net
> $ ./pkg2pkg Horde_Core pear.horde.org
> $ ./pkg2pkg imp pear.horde.org
> $ ./pkg2pkg PHPUnit pear.phpunit.de
> $ ./pkg2pkg PHP_CodeCoverage pear.phpunit.de
> $ ./pkg2pkg PHP_Parser pear.php.net
>> Another Horde developer mentioned that the "php-" prefix seems unnecessary
>> on the applications (like "horde" and "kronolith"). I agree that prefixing
>> those with "php-" does not make too much sense. It's a web application and
>> it is not really really relevant if it is coded in PHP or Ruby. The
>> applications were just named "horde3" and "kronolith2" before. Prefixing
>> with "php-" seems useful for the more library like elements like
>> "Horde_Date" ("php-horde-date"). But PEAR packages do not allow to
>> distinguish between "library" and "application" type so this is knowledge we
>> cannot evaluate automatically. If "php-" would be dropped for the
>> applications it would need to be dropped on the libraries as well to stick
>> with an automated approach. I'm tempted to do the package naming and the
>> dependency resolution manually for the applications. Or would the debian
>> naming conventions be okay with naming libs like "Horde_Date" just
> I think we need to keep the php- prefix at least for libraries. I
> agree that applications should be installable from their short name.
> But as applications can depend on other applications (with versionned
> dependencies), I propose to use the same algorithm for applications
> (aka php-horde-imp) and to add a "Provides: imp" manually to
> applications [provides].
Ah, that sounds good. I wasn't aware of this option. I will build
another set of test packages once you uploaded 0.3 and see if I still
find anything that could be problematic using this approach.
> This is the attached
> [provides]: See
> Note that Provides cannot be versionned.
>>> - Find a way to avoid requiring pear-horde-channel and like
>> It is probably not needed anymore but I will have to check how that works
>> with the Horde_Role package. That one is adding a channel specific
>> configuration variable. But it might not actually need the channel
>> definition and could live with a global configuration variable.
> I am not able to build any package without pear-horde-channel
>>> Other TODOs:
>>> - package and upload horde4
>> That is probably something only you can do. It seems extremely cumbersome to
>> check in all the packages to git. Is this something others can help with?
>> How does the repository get upgraded once there is a new release?
> There are still many things to do before that :-P
>>> - Move almost all php-* packages to the new method
>> Since you sent patches to my horde-components tool: Do you plan on using
>> that one for the Horde packages?
> Yes. At least to bootstrap the packages.
>> Would you like it to be useable for other
>> PEAR packages as well? So far recognition of remote packages is limited to
>> the ones from pear.horde.org but it would be easy to extend this to other
>> channels as well.
> I only maintain Horde and Kolab PEAR packages, but maybe others are
> I have attached some critical and some pedantic patches: can you apply them?
Sure, thanks a lot! I applied all beside 0006 which I will modify a bit.
> Updated TODO for pkg-php-tools:
> - implement the package naming algorithm
> - upload
> Updated TODO for "components":
> - use algorithm from pkg-php-tools (via a wrapper)
What should the wrapper do? I would assume I simply call the tool you
coded as the debian packaging helper in the components module relies
on your debian packaging helper anyway.
> - recursive template (for debian/source/format and debian/patches)
Ok, will do as soon as possible.
> - allow to apply several template folders (one generic and one specific)
Can you detail what you need here? How should the different folders be
> Updated TODO for Debian:
> - create ITPs for all packages
Sounds like this is something you will do.
> - write all the copyright files :-P
Sounds like this is something I will do :) ... We need to place a
COPYRIGHT or LICENSE file in each of the framework packages, right?
> - test, polish, test, polish
Once we are here we will broadcast this via horde.org and I also have
customers that will test those.
> - upload to experimental first
Hope this is not too far away :)
Thanks for all your efforts with this. I'm glad to see it moving.
The Horde Project
e: wrobel at horde.org
t: +49 700 6245 0000
pgp: 9703 43BE
More information about the pkg-php-pear