[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fedora-packaging] PHP packaging policy notes

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.


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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]