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

Sat Jul 23 21:44:22 UTC 2011

Hi Mathieu,

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

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

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

>
> Updated TODO for Debian:
> - create ITPs for all packages  
> (http://www.debian.org/devel/wnpp/index.en.html)

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.

Cheers,

Gunnar

>
>
>
> Regards
>
> --
> Mathieu

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de