[Fedora-packaging] PHP packaging policy notes

[Tim Jackson]

Jason L Tibbitts III wrote:

 > For PEAR modules, we currently have this proposal:
 >
 > http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec

To assist things and provide a real-world example I've rebuilt 
PEAR_Command_Packaging with its own spec file (almost) in line with the 
above proposal. As the person possibly most interested in this, I very 
much like Christopher's proposal and give it a +1.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185423
http://www.timj.co.uk/linux/specs/php-pear-PEAR-Command-Packaging.spec
http://www.timj.co.uk/linux/srpms/php-pear-PEAR-Command-Packaging-0.1.1-1.src.rpm

(NB the spec files that the above package *generates* aren't yet in line 
with the guidelines above; I'm not fiddling with patches for that until 
we settle on something)

> which still suffers from excess macroization (%{__rm} and other such
> horrors) but otherwise looks pretty good.

Personally I don't care either way about the "excess" macroization; the 
above package lacks this.

> We still need to decide whether php-pear-X should really provide php-X.  
 > At this point I'd vote against.

I agree.

> It looks like the :MODULE_COMPAT thing is a non-starter, so PHP
> packagers will just have to deal with incompatibilities that silently
> crop up.

NB that PEAR packages have the ability to define explicit PHP version 
deps/conflicts, which may assist things. Not least because 
PEAR_Command_Packaging will automatically pick these up and encode them 
in the specs (assuming the upstream authors use them, of course...)

> For PECL modules, I haven't seen much discussion.  What needs to
> happen here?

I think that's a whole lot less clear and ideally we should defer this 
for a little while, or at least not let it delay the approval of the 
PEAR packaging spec. For a start, I believe there are upstream (i.e. in 
PEAR) bugs that prevent the --register-only function working for PECL 
packages. However, Christopher Stone is investigating this. From my 
point of view, the PECL specs should ultimately look almost exactly like 
the PEAR specs, since the process (pear install --packagingroot etc.) 
should (in theory, though I don't think it currently does) work for PECL 
too.

> %define php_extdir %(php-config --extension-dir 2>/dev/null || echo %{_libdir}/php4)
> %define php_apiver %((echo %{default_apiver}; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1)
> 
> The second could use a bit of explanation, I think.

Not sure whether you're asking for clarification or just mentioning it 
for the record, but anyway here goes...

The point is to tie the package to an ABI version. Previously PECL 
packages were tied to a specific PHP version which meant they had to be 
rebuilt every time Core PHP was updated even if the ABI remained 
constant. The little macro above saves this unnecessary rebuilding by 
making sure the dep doesn't break if an ABI-compatible update of PHP 
takes place.


Tim