2 p.m.
Here are some open issues I see with the PHP guidelines. I don't
pretend that this is exhaustive:
1) The php(ABI) symbol. The current PHP package (in FC5) provides
php-api = 20041225; is that sufficient?
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.
3) It seems there are plenty of extensions which are neither PEAR nor
PECL. We need to figure out conventions for those.
4) Scriptlets for registering PEAR packages.
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. I don't know the exact details, but
we need to document them. (As a bonus, it seems that package has
a nonzero epoch as well.)
6) We need to work up specfile templates for all three situations if
appropriate and get them into fedora-rpmdevtools.
- J<
3:40 p.m.
On 6/29/06, Jason L Tibbitts III <tibbs(a)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.
4:02 p.m.
On Thu, 2006-06-29 at 13:40 -0700, Christopher Stone wrote:
On 6/29/06, Jason L Tibbitts III <tibbs(a)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.
4:11 p.m.
On 6/29/06, Ville Skyttä <ville.skytta(a)iki.fi> wrote:
On Thu, 2006-06-29 at 13:40 -0700, Christopher Stone wrote:
> On 6/29/06, Jason L Tibbitts III <tibbs(a)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).
I think the other templates should change to match mine. My style is
by far the cleanest and easiest on the eyes.
Why do we have a %{__rm} macro if it should not be used?
We should be consistent and use %{buildroot} so that we use the same
type of macros everywhere in the spec.
Indentation changed to line up Requires(postun):
%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?
This is not an issue. All pear packages are noarch and therefore no
%build or debuginfo packages need to be built.
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.
The %defines seem to work for me under mock, I'm not sure this is an issue.
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.
Cool, thx
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.
Yes, the only caveat is that a package like Foo_Bar really stores it's
files in a Foo/Bar/ directory, not a Foo_Bar/ directory as the current
spec file indicates.
I also added a
Provides: php-Foo-Bar = %{version}-%{release}
to meet the current (Draft) php guidelines, not sure I like this idea though
4:25 p.m.
On 6/29/06, Ville Skyttä <ville.skytta(a)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.
6:12 p.m.
>>>> "VS" == Ville Skytt <Ville> writes:
VS> Do those %defines at the top work in mock/plague setups where pear
VS> is not installed at the time the build begins?
Note that what's required here is that the spec maintains correct
syntax when those pear calls fail, as they will when the spec is first
"run" to extract its dependencies. In this case, they will evaluate
to something reasonable. and should be fine.
- J<
5:40 a.m.
Christopher Stone wrote:
I have put up what I think is a good template for pear modules here:
http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec
Great, thanks for the work on this. You seem to have simplified/improved
some aspects of what I'd come up with so far as a "best" spec as used in
a slightly less generic form in:
http://www.timj.co.uk/linux/specs/php-pear-PEAR-Command-Packaging.spec
I haven't had a chance to try it yet but will do so with
PEAR_Command_Packaging soon. Immediate (minor) points from a visual scan:
a) Requires: php - is this necessary? Surely a dep on php-pear(PEAR) is
sufficient, since that will itself pull PHP in?
b) Provides: php-Foo-Bar - what's the reasoning behind this?
c) You've removed all the pearrc cruft - if this really works (which it
looks like it should) then GREAT! I inherited that from previous work by
other people and have never really thought about it but logically since
we have a BR of php-pear, then the PEAR defaults should be appropriate
for our distro and there's no need to construct a temporary pearrc.
d) I think "%{__cp} -p package.xml" should be replaced with
"%{__install} -m 644 ...", just as a good practice thing
Tim
5:32 a.m.
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...
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
5:49 a.m.
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.
6:21 a.m.
On Fri, 2006-06-30 at 11:49 +0100, Tim Jackson wrote:
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 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.
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?
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.
6:49 a.m.
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
8:21 a.m.
On Fri, 2006-06-30 at 12:49 +0100, Tim Jackson wrote:
Ville Skyttä wrote:
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.
Yeah, I thought so :)
>>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.
Hm, that could be somewhat problematic. newrpmspec takes the package
name, so it would need to know how to transform that into a tarball
filename including the full path to it, and including the possible
version number in the tarball filename. newrpmspec's interface is not
set in stone, but I'd prefer if one could continue to do for example
"fedora-newrpmspec php-pear-Foo_Bar.spec" (and "emacs
php-pear-Foo_Bar.spec") and everything would Just Work. Ideas?
> 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
That would be trivial to add.
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.
Already doable with the -t option to fedora-newrpmspec, see --help for
details.
6503
days inactive
6504
days old
packaging@lists.fedoraproject.org
11 comments
4 participants
participants (4)
-
Christopher Stone -
Jason L Tibbitts III -
Tim Jackson -
Ville Skyttä