[Kolab-devel] PEAR packaging problems

[Richard Bos]

> We experienced some problems with PEAR packaging during preparations for
> the next Kolab server release. Maybe some packagers from other distros
> have additional insight or can make use of the information.

I encounter the same thing.
My specfiles contain:
# %setup -q -n %{prj}-%{version}  
# %__cp %{SOURCE0} %{prj}-%{version}.tgz  

The last line (%__cp) should not be needed as the package is
there already, but in an unpackage format.  The cp is there
because the pear install command expects a package, just
as you stated.

> From https://www.intevation.de/roundup/kolab/issue3260:
> 
> And in fact, looking at the PEAR packaging and installation mechanisms now
> I tend to say that they use a somewhat broken concept since they directly
> install from a tgz. And these tgz's are only installable as a package not
> when unpacked
> -> this irritated Thomas and after checking this I definitely agree.
> 
> There are two ways around this:

There is a third item that can be added to your list.  But this
won't be a workaroround but a solution.  Patch 'pear install', so it really knows how
to install a unpackage tarball.  Perhaps the same patch can also take care
that the channel information is in that case not needed, as that took
me some days to figure out, how to deal with that in an offline
virtual build image.


> 1) Patching the installed files. As there is no compilation we could apply               
> patches in the RPM_BUILD_ROOT. I consider this to be bad monkey patching and 
> would like to avoid this. If I remember the chat with Thomas correctly he
> also mentioned the same thing.

This is indeed a workaround.  RPM has a mechanism to apply patches, this
mechanism cannot be used with pear modules, which shows that the concept
is not correct => improve 'pear install'


> 2) Completing the unpacked tgz with package.xml from upstream and using
> this for installation. The drawback here is that it is somewhat complicated
> as you will need to modify the packages spec file and add the package.xml
> once you decide a package needs patching.

Sounds complicated...  Do you mean that the pear module is to be patched
before the rpm build?  If that is what you mean, is not a good idea either
as it decouples the native tarbal with the applied patches.  E.g. someone
who unpacks the src.rpm won't see what are the native sources, and what are
the patches....

> I consider solution 2) to be the more attractive one and I checked this in
> for Kolab_Filter as an example now.

> In general we should probably try to avoid patching and rather rely on
> upstream releases. Especially for the Kolab_* packages this is a simple
> thing for me to do. I could have also done this for the patch attached
> by Thomas here but I choose not to for demonstration purposes on how to
> patch a PEAR package.

Good demonstration :)

I hope, that a bug report will be opened against 'pear install' to make
it possible to install unpacked sources.  As you mentioned the package.xml
install file; in case a pear modules is patche, the patch should probably
also update the package.xml file.  But that seems doable, and can be part
of the patch that is applied against the pear module.

-- 
Richard