[pkg-php-pear] [Pkg-php-pear] On PEAR packaging

Sat Jul 23 18:58:28 UTC 2011

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).
>
> Great!

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
> http://pear.horde.org/channel.xml

(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
php-net-smtp
$ ./pkg2pkg PEAR pear.php.net
php-pear
$ ./pkg2pkg Horde_Core pear.horde.org
php-horde-core
$ ./pkg2pkg imp pear.horde.org
php-horde-imp
$ ./pkg2pkg PHPUnit pear.phpunit.de
php-phpunit
$ ./pkg2pkg PHP_CodeCoverage pear.phpunit.de
php-phpunit-php-codecoverage
$ ./pkg2pkg PHP_Parser pear.php.net
php-php-parser

> 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
> "horde-date"?

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

This is the attached 0007-Application-provides-its-application-short-name.patch

[provides]: See
<http://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual>.
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 interested.

[...]

I have attached some critical and some pedantic patches: can you apply them?

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)
- recursive template (for debian/source/format and debian/patches)
- allow to apply several template folders (one generic and one specific)

Updated TODO for Debian:
- create ITPs for all packages (http://www.debian.org/devel/wnpp/index.en.html)
- write all the copyright files :-P
- test, polish, test, polish
- upload to experimental first

Regards

-- 
Mathieu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pearname2dpkgname
Type: application/octet-stream
Size: 872 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20110723/c504c9c8/attachment-0008.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-pass-output-handler-to-distribute.patch
Type: application/octet-stream
Size: 2245 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20110723/c504c9c8/attachment-0009.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Fix-build-of-package-components.patch
Type: application/octet-stream
Size: 3244 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20110723/c504c9c8/attachment-0010.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Correct-shell-interpreter-path.patch
Type: application/octet-stream
Size: 1225 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20110723/c504c9c8/attachment-0011.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Specify-PHP-interpreter-with-shbang.patch
Type: application/octet-stream
Size: 2099 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20110723/c504c9c8/attachment-0012.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-Remove-dot-at-end-of-summaries-lintian-warning.patch
Type: application/octet-stream
Size: 7059 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20110723/c504c9c8/attachment-0013.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-various-package-files-enhancements.patch
Type: application/octet-stream
Size: 7661 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20110723/c504c9c8/attachment-0014.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007-Application-provides-its-application-short-name.patch
Type: application/octet-stream
Size: 1008 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20110723/c504c9c8/attachment-0015.obj>