On Thu, 2006-06-29 at 13:40 -0700, Christopher Stone wrote:

On 6/29/06, Jason L Tibbitts III tibbs@math.uh.edu wrote:

...

6. We need to work up specfile templates for all three situations if appropriate and get them into fedora-rpmdevtools.

I have put up what I think is a good template for pear modules here: http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec

Comments welcome.

Cosmetics: matching the existing style of other templates in rpmdevtools would be desirable (rm instead of %{__rm}, $RPM_BUILD_ROOT instead of %{buildroot}, indentation width at the top).

%build section missing, see eg. https://bugzilla.redhat.com/192422 why that may not be a good idea. The template is noarch, so the debuginfo problem isn't a problem here, but adding an empty %build section might avoid some nasty surprises in the future. By the way, are all pear module packages noarch?

Do those %defines at the top work in mock/plague setups where pear is not installed at the time the build begins? I think someone reported a problem with the similar approach taken in the python spec template in configurations where python is not in the initial set of packages (which could be a bug, but pear not being there is not). One possible fix would be to not do those defines, but to generate a filelist in %install and use that in %files, and drop the %defines altogether.

It would be nice to have rpmlint bugs reported instead of cluttering specfiles with comments and workarounds like the one in %post. I'll see if I can do something about it.

It's good to see the Foo_Bar/Foo-Bar placeholders in this phase, but they'll probably be emptied and auto-replaced by newrpmspec if/when the template enters rpmdevtools.

On 6/29/06, Ville Skyttä ville.skytta@iki.fi wrote:

Do those %defines at the top work in mock/plague setups where pear is not installed at the time the build begins? I think someone reported a problem with the similar approach taken in the python spec template in configurations where python is not in the initial set of packages (which could be a bug, but pear not being there is not). One possible fix would be to not do those defines, but to generate a filelist in %install and use that in %files, and drop the %defines altogether.

I tried changing the macros to just: %define peardir %(pear config-get php_dir 2> /dev/null) And this still worked under mock.

Jason L Tibbitts III wrote:

Here are some open issues I see with the PHP guidelines.

First of all, thanks for your work on this. As you and others may (or may not) have spotted from various activity in FE/RH Bugzilla/PEAR [1], I've spent a lot of time on PHP/RPM-related issues in the last few months and getting some concrete guidelines in place is great. I'm glad there is a bit of momentum behind this and I'm not the only one trying to make this stuff easier :)

(Background: I do a lot of PHP web application deployment and development, and package management/dependency resolution has always been a bugbear of mine; complete non-portability, complex setup and random problems due to missing deps are a regular feature of trying to deploy apps when all I want to do is "yum install [package]" and have a minimum of configuration necessary)

Note that my goal with the PEAR_Command_Packaging package in particular (forked, with the blessing and help of the PEAR maintainer, from PEAR core 'makerpm' command which it now obsoletes) has always been to make it so that "pear make-rpm-spec Foo_Bar.tgz" on Fedora will produce a spec compliant with FE guidelines. I'm not there yet, but getting closer. The php-pear-DB package that I submitted and which is in Extras was mostly a proof-of-concept to help establish what is a "good" spec file for a PEAR package.

1. The php(ABI) symbol. The current PHP package (in FC5) provides php-api = 20041225; is that sufficient?

Should be, I think although arguably "php" should provide php(ABI) or php-abi and "php-devel" should provide php(API) or php-api. The poor naming originated from my original suggestion over in bug #183227 I'm afraid :/

2. Somethig equivalent to perl(:MODULE_COMPAT_version). The base PHP package eventually provides a whole bunch of these indicating what releases a module could have been written against and still work. So php v6 can drop compatibility for anything before v4.2 and the package can drop the corresponding :MODULE_COMPAT symbols.

Sounds reasonable. I'm not familiar with how it's done in Perl; can we copy it?

3. It seems there are plenty of extensions which are neither PEAR nor PECL. We need to figure out conventions for those.

We already have some in FE like php-shout. Personally I'm not uncomfortable with that convention, the only caveat being that there's no immediate way of distinguishing what's a "core" extension and what's a third party one.

4. Scriptlets for registering PEAR packages.

Several different variations that I've used over time, and ideas from others have meant that personally I've settled on (for PEAR >=1.4.7) the following fragments, as featured in Chris S's spec template:

%post pear install --nodeps --soft --force --register-only \ %{xmldir}/Foo_Bar.xml >/dev/null ||:

%postun if [ "$1" -eq "0" ]; then pear uninstall --nodeps --ignore-errors --register-only \ Foo_Bar >/dev/null ||: fi

Indeed, these (minus the ||: which I will add) are used by default by PEAR_Command_Packaging both upstream and in my proposed FE package.

5. There is some functionality in php-pear which only made it in as of some specific version, I think 1.4.9, which needs to be there in order for something work work.

Maybe this:

http://pear.php.net/bugs/7093

Also I fixed some stuff related to --packagingroot in 1.4.7:

http://cvs.php.net/viewvc.cgi/pear-core/PEAR/Command/Install.php?view=log#re... http://pear.php.net/bugs/6480

there are also http://pear.php.net/bugs/6673 http://pear.php.net/bugs/6674

I would consider 1.4.7 as a minimum base version for future RPM-related stuff. Since 1.4.8 is broken, 1.4.9 is arguably the base.

Tim

[1] a non-exhaustive list includes:

RH #194852 - php Provides and Obsoletes mod_php RH #173980 - pear makerpm docs problem RH #183227 - PHP API needs encoding as a Provide ( php-api php(API) ) RH #173806 - php-pear does not have Provides: RH #175074 - php-pear provides php-pear(PEAR_PEAR) not php-pear(PEAR) RH #173808 - php-pear has too much bundled in it RH #173810 - php-pear should be built separately from main php rpm RH #173814 - pear makerpm does not generate deps on other PEAR packages RH #194583 - php should Provide php-posix RH #187891 - php package should provide mod_php, php-apache, php-apache2 or similar RH #173802 - template.spec naming convs RH #173804 - php core rpm does not have Provides RH #176725 - miscellaneous "pear makerpm" problems

PEAR #6373 - pear makerpm generates RPMs that cannot be uninstalled PEAR #6375 - "pear makerpm" misc. improvements (rpm-depname, rpm-release options) PEAR #6377 - "pear makerpm" post/postun improvements to cope with non-RPM installs PEAR #6378 - "pear makerpm" generates packages that conflict due to depdb/.channels PEAR #6480 - pear install --installroot option fails for pecl packages PEAR #5959 - post/postun prob PEAR #6047 - doc problem PEAR #6963 - Duplicate Requires deps generated in some cases PEAR #6971 - Create deps on php-[ext] PEAR #7118 - Remove "doc hack" from template spec file

PEAR package PEAR_Command_Packaging - http://pear.php.net/package/PEAR_Command_Packaging

Fedora Extras RH #176658 - php-pear-DB package RH #185423 - php-pear-PEAR-Command-Packaging package RH #196281 - php-manual-en package

Jason L Tibbitts III wrote:

6. We need to work up specfile templates for all three situations if appropriate and get them into fedora-rpmdevtools.

General point extending what I mentioned earlier: whilst I certainly wouldn't want for a minute to try to force it on anyone, would it be worth considering simply mandating "pear make-rpm-spec [package]" as the "official" way of generating a template spec? The main reasons are:

a) it seems a bit of duplication to have this in fedora-rpmdevtools when I'm working on it separately anyway, and the entire point why I took on PEAR_Command_Packaging was ultimately so that I could auto-generate specs for Fedora/RHEL. Upstream is of course done in a distro-neutral way, but my proposed FE package patches it (which is now simple thanks to the upstream changes I've made) to match Fedora conventions.

b) "pear make-rpm-spec" can incorporate additional time-saving logic that a static template with simple substitutions can't; some existing features include:

- prefilling %description

- generating stuff relating to docs dependent on whether or not the package actually includes docs (many don't)

Of course, there could be a hook in fedora-rpmdevtools which called out to "pear make-rpm-spec" if the above was liked but it was considered preferable to have all the template specs at least superficially generate-able from fedora-rpmdevtools.

I must stress that I'm not trying to "own" spec-template-generation for PEAR packages here, merely save duplication and hopefully see the existing work I've done in this area be useful. I'd warmly welcome any offers to co-maintain PEAR_Command_Packaging, the corresponding FE package, or both.

Tim

P.S. It doesn't really work atm, but my intention is also to make "pear make-rpm-spec" work for PECL packages too.

Ville Skyttä wrote:

I don't personally care where the spec templates come from, but I'd like all of them be generateable by fedora-newrpmspec. Its pre-filling capabilities are pretty limited kludges at the moment, and sounds like your stuff is capable of much more already, so as long as the result meets the guidelines, I'd be glad to apply patches that add such a hook.

OK, great. I think you'd have a hard time replicating the *potential* pre-filling capabilities of PEAR_Command_Packaging, since it's intimately tied into PEAR and knows how to analyse the package's XML file, work out deps etc.

In fact what I didn't mention before is that it does of course also auto-generate the Requires:, which is a major bonus.

As soon as we're all settled on a template spec, high on my priority list will be making php-pear-PEAR_Command_Packaging generate specs that comply with that template format, including upstream changes if required (although hopefully the development has reached a sufficiently advanced stage now that upstream changes should be minimal or zero; most can simply be achieved by patching/replacing the template.spec provided by php-pear-PEAR-Command-Packaging in %{peardir}/data/PEAR_Command_Packaging/template.spec)

...

From the hook POV, it would be easiest if "pear make-rpm-spec" would

take the package name in a command line option, and would be capable of emitting the generated template to stdout, perhaps conditionally based on existence of some other command line option. Maybe it already works that way?

Nearly. Currently it takes the *filename* of a package tarball and outputs the resulting template to stdout. Bear in mind that to do all the clever stuff it does, it needs to have a copy of the actual package tarball, not just the package name. But then if you're about to build an RPM, you're going to need this anyway...

If there was enough demand I could build in a hook to go off to pear.php.net and download the package tarball given a package name, but unless there's a compelling reason this is probably adding unnecessary complexity when a "wget" prior to calling make-rpm-spec will do the trick.

I wouldn't like a dependency on pear in rpmdevtools, so on pear execution failures (eg. when not installed), newrpmspec should probably just fall back to the generic template.

Fair enough; I'd had the exact same thought. In that case, there should probably also be

a) an informational message telling you that this is happening

b) a way to get newrpmspec to use the generic template *in any case*, so that if (for some weird reason) you don't want to download the actual PEAR package and just get a template spec based on the package *name* alone, you can.

Tim