PHP packaging policy notes

[Joe Orton]

cc'ing Tim since we had lots of discussion about much of this stuff 
already and I'm not sure if he's on fedora-packaging (I didn't even know 
that list existed...)

I was planning to add a "php-abi = <PHP_API_VERSION>" definition for C 
ABI versioning rather than php(ABI).

Versioning language features in PHP a la MODULE_COMPAT_* is just not 
going to be feasible; the language is not well-defined enough nor stable 
enough for us to try and enforce versioning; plus stuff like 
"zend.ze1_compatibility_mode" means the exposed language is dependent on 
config options anyway.

I don't see why it's necessary for a PEAR package to require 
php-pear(PEAR); that is somewhat equivalent to an RPM having "Requires: 
rpm"; it should be sufficient and correct for PEAR packages to simply 
"Requires: php-pear" AFAICS.

Why should a PEAR package for foo provide php-foo?  Not sure that's a 
good idea.

On "Other Packages": an application written in PHP or such like should 
not have a php- prefix at all.  A Smarty package should be called 
"smarty" (following the "upper-case is evil" rule of packaging).

joe

[Tom Callaway]

On Fri, 2006-06-30 at 10:52 +0100, Joe Orton wrote:

>  On "Other Packages": an application written in PHP or such
> like should 
>  not have a php- prefix at all.  A Smarty package should be called 
>  "smarty" (following the "upper-case is evil" rule of packaging).
Indeed, this is correct. The php-* (and php-pecl/pear) namespace are
reserved for items that add new functionality/modules to PHP, not for
applications written in PHP.

~spot
-- 
Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[Paul Howarth]

Tom 'spot' Callaway wrote:
>  On Fri, 2006-06-30 at 10:52 +0100, Joe Orton wrote:
>  
> > On "Other Packages": an application written in PHP or such like should 
> > not have a php- prefix at all.  A Smarty package should be called 
> > "smarty" (following the "upper-case is evil" rule of packaging).
>  
>  Indeed, this is correct. The php-* (and php-pecl/pear) namespace are
>  reserved for items that add new functionality/modules to PHP, not for
>  applications written in PHP. 
Smarty is not an application in itself; it's a library of PHP code used 
in other applications. As such it adds functionality to PHP...

Paul.

[Tom Callaway]

On Fri, 2006-06-30 at 14:53 +0100, Paul Howarth wrote:
>  Tom 'spot' Callaway wrote:
>  > On Fri, 2006-06-30 at 10:52 +0100, Joe Orton wrote:
>  > 
>  >> On "Other Packages": an application written in PHP or such like should
>
>  >> not have a php- prefix at all.  A Smarty package should be called 
>  >> "smarty" (following the "upper-case is evil" rule of
> packaging).
>  > 
>  > Indeed, this is correct. The php-* (and php-pecl/pear) namespace are
>  > reserved for items that add new functionality/modules to PHP, not for
>  > applications written in PHP.
>  
>  Smarty is not an application in itself; it's a library of PHP code used 
>  in other applications. As such it adds functionality to PHP... 
Then (in the case of smarty), it does need to be in the php namespace. I
think if its not a pecl/pear, but it adds functionality to PHP, then it
should be php-%{name}.

~spot
-- 
Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[Paul Howarth]

Tom 'spot' Callaway wrote:
>  On Fri, 2006-06-30 at 14:53 +0100, Paul Howarth wrote:
> > Tom 'spot' Callaway wrote:
> >> On Fri, 2006-06-30 at 10:52 +0100, Joe Orton wrote:
> >>
> >>> On "Other Packages": an application written in PHP or such like
> should 
> >>> not have a php- prefix at all.  A Smarty package should be called 
> >>> "smarty" (following the "upper-case is evil" rule of
> packaging).
> >> Indeed, this is correct. The php-* (and php-pecl/pear) namespace are
> >> reserved for items that add new functionality/modules to PHP, not for
> >> applications written in PHP.
> > Smarty is not an application in itself; it's a library of PHP code used 
> > in other applications. As such it adds functionality to PHP...
>  
>  Then (in the case of smarty), it does need to be in the php namespace. I
>  think if its not a pecl/pear, but it adds functionality to PHP, then it
>  should be php-%{name}. 
Which is good, since it's already in Extras as php-Smarty

Paul.

[Christopher Stone]

As it is now, the php-pecl spec files have a group of
Development/Language and the php-pear spec file use a group of
Development/Libraries

Shouldn't this be reversed?  Afterall, the pecl packages are packaged
with a .so file and the pear packages are all .php files.  So I am a
little confused on what the groups should be.

[Christopher Stone]

There are going to be many pear packages which share a directory such
as Auth/ or Image/ or Net/ etc.

The simple rule of thumb in this case is that if there is no clear
heirarchy of directory ownership, then all packages must own that
directory.

This should be added to the PHP packaging guidelines since this goes
against the Fedora Extras guidelines which state that the package must
not own files or directories owned by other packages.

[Tom Callaway]

On Fri, 2006-06-30 at 14:48 -0700, Christopher Stone wrote:
>  There are going to be many pear packages which share a directory
> such
>  as Auth/ or Image/ or Net/ etc.
>  
>  The simple rule of thumb in this case is that if there is no clear
>  heirarchy of directory ownership, then all packages must own that
>  directory.
>  
>  This should be added to the PHP packaging guidelines since this goes
>  against the Fedora Extras guidelines which state that the package must
>  not own files or directories owned by other packages. 
Instead of adding it to the PHP packaging guideline, the directory
ownership rule should be clarified in the main guideline.

~spot
-- 
Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[Christopher Stone]

On 6/30/06, Christopher Stone <chris.stone(a)gmail.com&gt; wrote:
>  As it is now, the php-pecl spec files have a group of
>  Development/Language and the php-pear spec file use a group of
>  Development/Libraries
>
>  Shouldn't this be reversed?  Afterall, the pecl packages are packaged
>  with a .so file and the pear packages are all .php files.  So I am a
>  little confused on what the groups should be. 
Okay well I've given this some thought and I think both pecl and pear
packages should be grouped under Development/Libraries.  pecl packages
provide extensions to the languge just like pear packages do, only
they are written in C.  It might just be a matter of semantics and
someone with a better understanding of the Group tag definitions knows
better.

[Christopher Stone]

I have simplified my pear spec file slightly:
http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec

I think we should have an almost identical spec file for pecl
packages, except we replace pear with pecl.

I tried converting Remi's php-pecl-zip spec file in this manner but it
does not build properly, there may be some bugs we need to work out
first.

However I think if the command `pecl install zip-alpha` registers the
zip component so it shows up on a `pecl list` command, then the
php-pecl-zip rpm should also register this component in the same way.

Thoughts/Comments?

[Joe Orton]

On Fri, Jun 30, 2006 at 09:21:29AM -0500, Tom 'spot' Callaway wrote:
>  On Fri, 2006-06-30 at 14:53 +0100, Paul Howarth wrote:
>  > Tom 'spot' Callaway wrote:
>  > > On Fri, 2006-06-30 at 10:52 +0100, Joe Orton wrote:
>  > > 
>  > >> On "Other Packages": an application written in PHP or such like
> should 
>  > >> not have a php- prefix at all.  A Smarty package should be called 
>  > >> "smarty" (following the "upper-case is evil" rule of
> packaging).
>  > > 
>  > > Indeed, this is correct. The php-* (and php-pecl/pear) namespace are
>  > > reserved for items that add new functionality/modules to PHP, not for
>  > > applications written in PHP.
>  > 
>  > Smarty is not an application in itself; it's a library of PHP code used 
>  > in other applications. As such it adds functionality to PHP...
>  
>  Then (in the case of smarty), it does need to be in the php namespace. I
>  think if its not a pecl/pear, but it adds functionality to PHP, then it
>  should be php-%{name}. 
Smarty does not "add functionality to PHP" any more than libxml "adds 
functionality to C".  If Smarty was installed somewhere the default 
include_path would pick up you could make a case; but it's not.  It's 
just a library of PHP code.

joe

[Christopher Stone]

On 6/30/06, Joe Orton <jorton(a)redhat.com&gt; wrote:
>  I don't see why it's necessary for a PEAR package to require
>  php-pear(PEAR); that is somewhat equivalent to an RPM having "Requires:
>  rpm"; it should be sufficient and correct for PEAR packages to simply
>  "Requires: php-pear" AFAICS. 
I think the php-pear(PEAR) should remain.  It refers the the class,
and therefore uses the class name, so something like php-pear-Foo-Bar
would have a provides php-pear(Foo_Bar) which is the actual name of
the class rather than some Fedora package naming standard.

See my package:
http://tkmame.retrogames.com/fedora-extras/php-pear-Payment-Process.spec
Where I have many such pear class requirements.  These are listed on
the pear download pages, for example:
http://pear.php.net/package/Payment_Process/download

The whole php-pear(Foo) thing is done to provide a reference to the
true class name and to provide better cross compatibility between
distributions.

>  Why should a PEAR package for foo provide php-foo?  Not sure that's a
>  good idea. 
I'm not sure this is a good idea either, and I'm not sure of why it's
part of the PHP packaging guidelines.

>  On "Other Packages": an application written in PHP or such like should
>  not have a php- prefix at all.  A Smarty package should be called
>  "smarty" (following the "upper-case is evil" rule of packaging).
I would agree except that Smarty is not an application, it is a
library meant to be used by applications.  I think the php-Smarty as a
name is fine.

[Christopher Stone]

On 7/2/06, Christopher Stone <chris.stone(a)gmail.com&gt; wrote:
>  On 6/30/06, Joe Orton <jorton(a)redhat.com&gt; wrote:
>  > Why should a PEAR package for foo provide php-foo?  Not sure that's a
>  > good idea.
>
>  I'm not sure this is a good idea either, and I'm not sure of why it's
>  part of the PHP packaging guidelines.
>  
Okay, I found out why:

[17:31] <spot> but where there is no name conflict
[17:31] <spot> each package should Provide: php-FOO = %{version}-%{release}
[17:31] <spot> this way, we should catch the yum install php-FOO case

So this is okay, except that it needs to be added to the wiki page
(except where there is no name conflict) for example:

php-xmlrpc and php-pear-xmlrpc -- I'm *still* confused on these two ;-)

[Christopher Stone]

On 7/2/06, Christopher Stone <chris.stone(a)gmail.com&gt; wrote:
>  php-xmlrpc and php-pear-xmlrpc -- I'm *still* confused on these
> two ;-) 
Actually, I guess the pear version would be php-pear-XML-RPC and
Provide php-XML-RPC, so I guess even in this case we are okay.

[Jason L Tibbitts III]

I think we need to get moving on this; I'd hope to have something
which has at least some chance of passing by the next meeting.

For PEAR modules, we currently have this proposal:

http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec

which still suffers from excess macroization (%{__rm} and other such
horrors) but otherwise looks pretty good.  We still need to decide
whether php-pear-X should really provide php-X.  At this point I'd
vote against.

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.


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

For extensions like php-shout and other packages like php-Smarty, we
really don't have any guidelines at all, and we need some.

I'm not familiar enough with the issues to even know where to start.
Both PECL and plain extensions seem to need a couple of defines; the
existing php-pecl-apc package (which somehow was approved recently for
Extras) uses these:

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

 - J<

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

(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

[Christopher Stone]

On 7/3/06, Tim Jackson <lists(a)timj.co.uk&gt; wrote:
>  Jason L Tibbitts III wrote:
>  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... 
I do not like the way patches are handled in this case.  I have
reworked the spec file here:
http://tkmame.retrogames.com/fedora-extras/php-pear-PEAR-Command-Packagin...

Where the patches are done normally.  Perhaps we should use this type
of install as a standard?  That is, untarring the tarball, making any
necessary patches, then installing with the .xml file?

An update SRPM with fixed patches is here:
http://tkmame.retrogames.com/fedora-extras/php-pear-PEAR-Command-Packagin...

[Tim Jackson]

Christopher Stone wrote:

>  On 7/3/06, Tim Jackson <lists(a)timj.co.uk&gt; wrote:
> > 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... 
>  I do not like the way patches are handled in this case.  I have
>  reworked the spec file here:
>  http://tkmame.retrogames.com/fedora-extras/php-pear-PEAR-Command-Packagin...  
Looks fine to me. I agree that's more readable.

>  Where the patches are done normally.  Perhaps we should use this
> type
>  of install as a standard?  That is, untarring the tarball, making any
>  necessary patches, then installing with the .xml file? 
Good idea. The end result should be exactly the same. Although it does 
add an extra step for packages that *don't* need patching. (Which 
hopefully most won't; PEAR_Command_Packaging should be an exception)

Tim

[Ralf Corsepius]

On Tue, 2006-07-04 at 09:58 +0100, Tim Jackson wrote:
>  Christopher Stone wrote:
>  
>  > On 7/3/06, Tim Jackson <lists(a)timj.co.uk&gt; wrote:
>  >> 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... 
>  
>  > I do not like the way patches are handled in this case.  I have
>  > reworked the spec file here:
>  > http://tkmame.retrogames.com/fedora-extras/php-pear-PEAR-Command-Packagin... 
>  
>  Looks fine to me. I agree that's more readable. 
I disagree on this:
..
Requires(post): php-pear
Requires(pre):  php-pear
..
%post
pear install --nodeps --soft --force --register-only %{xmldir}/PEAR_Command_Packaging.xml
>/dev/null ||:
..
%postun
if [ "$1" -eq "0" ]; then
    pear uninstall --nodeps --ignore-errors --register-only PEAR_Command_Packaging
>/dev/null ||:
fi

Also c.f. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197561

Ralf

[Tim Jackson]

Ralf Corsepius wrote:

>  I disagree on this:
>  ..
>  Requires(post): php-pear
>  Requires(pre):  php-pear
>  ..
>  %post
>  pear install --nodeps --soft --force --register-only %{xmldir}/PEAR_Command_Packaging.xml
> >/dev/null ||:
>  ..
>  %postun
>  if [ "$1" -eq "0" ]; then
>      pear uninstall --nodeps --ignore-errors --register-only PEAR_Command_Packaging
> >/dev/null ||:
>  fi
>  
>  Also c.f. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197561 
Fair point I think. No problem by me.

Tim

[Christopher Stone]

On 7/3/06, Jason L Tibbitts III <tibbs(a)math.uh.edu&gt; wrote:
>  I think we need to get moving on this; I'd hope to have
> something
>  which has at least some chance of passing by the next meeting.
>
>  For PEAR modules, we currently have this proposal:
>
>  http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec
>
>  which still suffers from excess macroization (%{__rm} and other such
>  horrors) but otherwise looks pretty good.  We still need to decide
>  whether php-pear-X should really provide php-X.  At this point I'd
>  vote against. 
I have updated the template:
-removed excess macroization (ugh)
-used new (untested) install using xml instead of tar method to allow
for proper patching (I will test this out with my pear packages and
make sure it works fine)
-install .xml file with install command instead of cp command
-use full path to pear in %post/un scriptlets (there was some
discussion that this should be done? if so, can we have a %{__pear}
macro defined so I can use this here?
-changed %files to have %{peardir}/Foo instead of Foo_Bar
-removed "Provides: php-Foo-Bar" line

[Tim Jackson]

Christopher Stone wrote:

>  On 7/2/06, Christopher Stone <chris.stone(a)gmail.com&gt; wrote:
> > On 6/30/06, Joe Orton <jorton(a)redhat.com&gt; wrote:
> > > Why should a PEAR package for foo provide php-foo?  Not sure that's a
> > > good idea.
> >
> > I'm not sure this is a good idea either, and I'm not sure of why it's
> > part of the PHP packaging guidelines.
> >
>  Okay, I found out why:
>  
>  [17:31] <spot> but where there is no name conflict
>  [17:31] <spot> each package should Provide: php-FOO = %{version}-%{release}
>  [17:31] <spot> this way, we should catch the yum install php-FOO case 
Not sure if I'm on my own here, but this seems like a lot of namespace 
clutter for little benefit. What's the problem with "yum install 
php-pear-FOO"?

Tim

[Jason L Tibbitts III]

> >>>> "TJ" == Tim Jackson
> <lists(a)timj.co.uk&gt; writes: 
TJ> Not sure if I'm on my own here, but this seems like a lot of
TJ> namespace clutter for little benefit.  What's the problem with
TJ> "yum install php-pear-FOO"?

I believe spot's reasoning was that we don't want
users to have to know whether what they want is in a PEAR or PECL
module.  I'm not sure it's worth the inevitable namespace collision.

 - J<

[Tim Jackson]

Jason L Tibbitts III wrote:

> >>>>> "TJ" == Tim Jackson
> <lists(a)timj.co.uk&gt; writes:
>  
>  TJ> Not sure if I'm on my own here, but this seems like a lot of
>  TJ> namespace clutter for little benefit.  What's the problem with
>  TJ> "yum install php-pear-FOO"?
>  
>  I believe spot's reasoning was that we don't want
>  users to have to know whether what they want is in a PEAR or PECL
>  module.  I'm not sure it's worth the inevitable namespace collision. 
I can see the reasoning (Tom?), but:

a) PEAR and PECL are fundamentally two quite different things. If 
someone is specifically installing a PEAR or PECL package (as opposed to 
getting one pulled in as a dep of something else, in which case the 
naming is mostly irrelevant) then presumably they already know what it 
is and how to use it. If they don't know whether it's a PEAR or a PECL 
module, they're not likely to have much success using it, not least 
because PECL extends the language core with (normally procedural) 
functions that don't need external requires() whereas PEAR modules are 
PHP classes that normally need explicit requires() when they are used.

b) Even ignoring (a), personally I think the namespace clutter and 
possible collisions mean that it's not really worth it.

Tim

[Joe Orton]

On Mon, Jul 03, 2006 at 08:54:14AM -0500, Jason L Tibbitts III wrote:
>  >>>>> "TJ" == Tim Jackson
> <lists(a)timj.co.uk&gt; writes:
>  
>  TJ> Not sure if I'm on my own here, but this seems like a lot of
>  TJ> namespace clutter for little benefit.  What's the problem with
>  TJ> "yum install php-pear-FOO"?
>  
>  I believe spot's reasoning was that we don't want
>  users to have to know whether what they want is in a PEAR or PECL
>  module.  I'm not sure it's worth the inevitable namespace collision. 
I completely agree with Tim.  You *have* to know whether the package is 
a PEAR or PECL extension to be able to use it; we should not attempt to 
hide this distinction from anybody, it will only lead to confusion and 
future conflicts.

joe

[Tom Callaway]

On Tue, 2006-07-04 at 11:37 +0100, Joe Orton wrote:
>  On Mon, Jul 03, 2006 at 08:54:14AM -0500, Jason L Tibbitts III
> wrote:
>  > >>>>> "TJ" == Tim Jackson <lists(a)timj.co.uk&gt; writes:
>  > 
>  > TJ> Not sure if I'm on my own here, but this seems like a lot of
>  > TJ> namespace clutter for little benefit.  What's the problem with
>  > TJ> "yum install php-pear-FOO"?
>  > 
>  > I believe spot's reasoning was that we don't want
>  > users to have to know whether what they want is in a PEAR or PECL
>  > module.  I'm not sure it's worth the inevitable namespace collision.
>  
>  I completely agree with Tim.  You *have* to know whether the package is 
>  a PEAR or PECL extension to be able to use it; we should not attempt to 
>  hide this distinction from anybody, it will only lead to confusion and 
>  future conflicts. 
Consider that provision dropped, I was never overly attached to it
anyways. :)

~spot
-- 
Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[Jason L Tibbitts III]

> >>>> "TC" == Tom Callaway <Tom> writes:
TC> Consider that provision dropped, I was never overly attached to it
TC> anyways. :)

I've removed it from the draft.  Can we agree to excise the
:MODULE_COMPAT stuff as well?

 - J<

[Tom Callaway]

On Tue, 2006-07-04 at 11:15 -0500, Jason L Tibbitts III wrote:
>  >>>>> "TC" == Tom Callaway <Tom>
> writes:
>  
>  TC> Consider that provision dropped, I was never overly attached to it
>  TC> anyways. :)
>  
>  I've removed it from the draft.  Can we agree to excise the
>  :MODULE_COMPAT stuff as well? 
Sure, especially if the php owner doesn't see the value in adding it.

~spot
-- 
Tom "spot" Callaway: Red Hat Technical Team Lead || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

[Christopher Stone]

Can we have some macros defined in the /usr/lib/rpm/macros file?

I would like:
%__pear /usr/bin/pear
%__pecl /usr/bin/pecl

and perhaps some pear macros similar to the perl macros:
%perl_sitearch  %(eval "`%{__perl} -V:installsitearch`"; echo $installsitearch)
%pear_phpdir %(eval "`%{__pear} config-get php_dir`"; echo $php_dir)

or something similar to this?

[Jason L Tibbitts III]

> >>>> "CS" == Christopher Stone
> <chris.stone(a)gmail.com&gt; writes: 
CS> Can we have some macros defined in the /usr/lib/rpm/macros file?

I agree that it might be nice, but I don't think it reasonable to wait
for Red Hat to push an RPM update before we can get guidelines out.
We could consider recommending:

%{!?__php:  %define __php  /usr/bin/php}
%{!?__pear: %define __pear /usr/bin/pear}
%{!?__pecl: %define __pecl /usr/bin/pecl}

Which would work now and would continue to work even if the core RPM
package is updated.  After we no longer support any releases that
don't have the macros defined by default, we could drop those three
defines from the guidelines and the templates.

 - J<

[Nicolas Mailhot]

Le mardi 04 juillet 2006 à 13:16 -0500, Jason L Tibbitts III a écrit :
>  >>>>> "CS" == Christopher Stone
> <chris.stone(a)gmail.com&gt; writes:
>  
>  CS> Can we have some macros defined in the /usr/lib/rpm/macros file?
>  
>  I agree that it might be nice, but I don't think it reasonable to wait
>  for Red Hat to push an RPM update before we can get guidelines out. 
Can't the core php package drop a macros file in /etc/rpm/ ?

Regards,

-- 
Nicolas Mailhot

[Enrico Scholz]

tibbs(a)math.uh.edu (Jason L Tibbitts III) writes:

>  I agree that it might be nice, but I don't think it reasonable to
> wait
>  for Red Hat to push an RPM update before we can get guidelines out.
>  We could consider recommending:
>
>  %{!?__php:  %define __php  /usr/bin/php}
>  %{!?__pear: %define __pear /usr/bin/pear}
>  %{!?__pecl: %define __pecl /usr/bin/pecl} 
Please use '%global' but not '%define' for such macros which might be
added to official guidelines. %define in such expressions is broken :

      https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=147238


Enrico

[Jason L Tibbitts III]

> >>>> "TC" == Tom Callaway <Tom> writes:
TC> Sure, especially if the php owner doesn't see the value in adding
TC> it.

OK, it's now gone; in it's place is

Requires: php >= current PHP version

Perl would use Requires: perl(:MODULE_COMPAT_current-perl-version)
here.

I suppose we'll need a macro to extract the current PHP version.

%define php_version %(php-config --version 2>/dev/null || echo 0)

Should we use the full path to php-config here?  The Ruby specfile
template doesn't.  The Ruby template also wraps its macros like
%{!?ruby_sitelib: ...}; do we need to do the same?

Here are the macros I've seen, renamed to be consistent with what
other language templates use (php_*).  I also replaced any default
values provided with either "undefined" or "0".   These macros only
have to result in something which is syntactically correct when things
aren't yet installed; I'm concerned that providing a meaningful
default value would both become outdated (as uses of "php4" will soon
be) and might still produce something that looks OK even when a BR is
missing.

For PEAR modules:

%define php_peardir     %(pear config-get php_dir  2> /dev/null || echo undefined)
%define php_peardatadir %(pear config-get data_dir 2> /dev/null || echo undefined)
%define php_pearxmldir  %{php_peardir}/.pkgxml
%define php_version     %(php-config --version 2>/dev/null || echo 0)


For PECL modules:

%define php_apiver  %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API =>
//p') | tail -1)
%define php_extdir  %(php-config --extension-dir 2>/dev/null || echo
"undefined")
%define php_version %(php-config --version 2>/dev/null || echo 0)


Modules which are neither PEAR nor PECL will need to use whichever
locations and macros are appropriate.  Extensions like php-shout will
need the PECL defines, for example.

I looked at php-Smarty and found that it gets installed essentially as
a web application.  It drops itself in %_datadir/Smarty.  At first
glance that seems pretty odd.  I guess it's not really a PHP module at
all.

Here are the subbested %post and %postun scriptlets from the ticket
Ralf cited earlier:

Requires(%post): /usr/bin/pear
Requires(%postun): /usr/bin/pear

%post
/usr/bin/pear install --nodeps --soft --force --register-only
%{php_pearxmldir}/PEAR_Command_Packaging.xml >/dev/null

%postun
if [ "$1" -eq "0" ]; then
  /usr/bin/pear uninstall --nodeps --ignore-errors --register-only PEAR_Command_Packaging
>/dev/null
fi

I removed the ||: bits as my understanding is that they are no longer
required or wanted.

Do PECL modules need any scriptlets?

Finally, should we consider providing macros to assist in converting
between the various representation of the package name?  We have
php-pear-module-name, PEAR_Module_name and probably a few others.

 - J<

[Christopher Stone]

On 7/4/06, Jason L Tibbitts III <tibbs(a)math.uh.edu&gt; wrote:
>  >>>>> "TC" == Tom Callaway <Tom>
> writes:
>
>  TC> Sure, especially if the php owner doesn't see the value in adding
>  TC> it.
>
>  OK, it's now gone; in it's place is
>
>  Requires: php >= current PHP version
>
>  Perl would use Requires: perl(:MODULE_COMPAT_current-perl-version)
>  here.
>
>  I suppose we'll need a macro to extract the current PHP version.
>
>  %define php_version %(php-config --version 2>/dev/null || echo 0)
>
>  Should we use the full path to php-config here?  The Ruby specfile
>  template doesn't.  The Ruby template also wraps its macros like
>  %{!?ruby_sitelib: ...}; do we need to do the same? 
If I understand things correctly, there are basically two types of php
packages, those written in C or some other language which create a .so
file which gets loaded by the php.ini file, and those that are written
in php which only add .php files otherwise known as "class libraries".
 pecl modules create .so files, pear modules are only .php files, and
other modules can be either or.  For example, php-Smarty is only .php
files and php-mysql adds .so and .ini files.

"pear" and "pecl" packages are just like php-Foo packages except that
they have been classified into one of these two types and are tared in
a way in which they can be installed using the /usr/bin/pear or
/usr/bin/pecl commands.

Packages which are .php files only such as php-Smarty or php-pear-Foo
need only require php >= version they say they require, or if they do
not say, then php >= current version (or no version) should be fine.
I have some php-pear packages which specifically indicate they need
php >= 4.2.0 some that say they need php >= 4.3.0.  If these versions
are specified by the package, they should be indicated in the spec
file (IMO).

Packages which make .so files and load them in .ini files should
require a php-api version.  The api version can be obtained like so:

%define apiver %((phpize --version 2>/dev/null || echo 'PHP Api
Version: 20041225' ) | sed -n '/PHP Api Version/ s/.*:  *//p')
Requires: php-api >= %{apiver}

packages such as php-mysql or php-pecl-Foo should have this.

>  For PEAR modules:
>
>  %define php_peardir     %(pear config-get php_dir  2> /dev/null || echo undefined)
>  %define php_peardatadir %(pear config-get data_dir 2> /dev/null || echo undefined)
>  %define php_pearxmldir  %{php_peardir}/.pkgxml
>  %define php_version     %(php-config --version 2>/dev/null || echo 0)
>
>
>  For PECL modules:
>
>  %define php_apiver  %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API =>
> //p') | tail -1)
>  %define php_extdir  %(php-config --extension-dir 2>/dev/null || echo
> "undefined")
>  %define php_version %(php-config --version 2>/dev/null || echo 0) 
Note pear and pecl modules both need to get path infomation in the same way:
%define php_peardir     %(pear config-get php_dir  2> /dev/null ||
echo undefined)
%define php_peardir     %(pecl config-get php_dir  2> /dev/null ||
echo undefined)

Say calling this macro "php_peardir" is not a good idea, instead a
better name would be "php_phpdir", "php_datadir" etc..

I think it was determined that the API macro of:
%define apiver %((phpize --version 2>/dev/null || echo 'PHP Api
Version: 20041225' ) | sed -n '/PHP Api Version/ s/.*:  *//p')

was considered "better" for some reason, I will have to find out which
bug this was commented on to try and find out why.

>  I looked at php-Smarty and found that it gets installed essentially
> as
>  a web application.  It drops itself in %_datadir/Smarty.  At first
>  glance that seems pretty odd.  I guess it's not really a PHP module at
>  all. 
Smarty is not an application, it is just like any other pear package
in that it adds a "class library" which can be used by php developers.
 If there is something wrong with installing it in %_datadir, where
should it go instead?

>  Here are the subbested %post and %postun scriptlets from the ticket
>  Ralf cited earlier:
>
>  Requires(%post): /usr/bin/pear
>  Requires(%postun): /usr/bin/pear 
How is this different than:
Requires(post): php-pear

>  %post
>  /usr/bin/pear install --nodeps --soft --force --register-only
> %{php_pearxmldir}/PEAR_Command_Packaging.xml >/dev/null
>
>  %postun
>  if [ "$1" -eq "0" ]; then
>    /usr/bin/pear uninstall --nodeps --ignore-errors --register-only PEAR_Command_Packaging
> >/dev/null
>  fi
>
>  I removed the ||: bits as my understanding is that they are no longer
>  required or wanted. 
Why are these no longer wanted?  First I am told to put them in, and
now I am told not to.  Can we get clarification on why and if it is
better practice not to, can we update the Scriptlets wiki page to
indicate this?

>  Do PECL modules need any scriptlets? 
PECL modules will need the exact same scriptlets only they will use
the /usr/bin/pecl command instead of the /usr/bin/pear command.
However /usr/bin/pecl is currently broken and a bug needs to be filed
for this upstream.

>  Finally, should we consider providing macros to assist in converting
>  between the various representation of the package name?  We have
>  php-pear-module-name, PEAR_Module_name and probably a few others. 
Sure, is fedora-newrpmspec powerfull enough to do this?  I think this
is all that is required:

Provides: php-pear-Foo-Bar >= %{version}-%{release}
Provides: php-pear(Foo_Bar) >= %{version}-%{release}

If we want to cater to newbs I really don't think we will ever have
any name collisions with:

Provides: php-Foo-Bar >= %{version}-%{release}
Provides: php-Foo_Bar >= %{version}-%{release}

In the rare (and possibly will never happen) case that there is a name
collision we can require that these provides be entered manually to
avoid such collision.

[Christopher Stone]

I would also like to get clarification on Groups, everyone seems to
have their own ideas as to what should be "System
Environment/Libraries", "Development/Libraries" or
"Development/Languages"

Should all php-pecl-* packages be grouped as "Development/Languages"?
Should all php-pear packages be "Development/Libraries"? This is the
status-quo now.

When should a package be "System Environment" vs. "Development"?  I
cannot find a definition on what this means. I went through some
perl-* packages and python-* packages and Groups are all over the
place, python-kid for example is grouped as an Application.

I think some definitions and example packages in the Groups wiki page
would be nice to have as a reference.

> From what I can tell right now, Group tags are not really considered
that important and randomness seems to be the accepted practice.  I
have not seen any response to my Group tag questions on this mailing
list and discussions on IRC lead to different answers by different
people.  So I have to assume that the Groups as they stand right now
currently have no definition?

[Jason L Tibbitts III]

> >>>> "CS" == Christopher Stone
> <chris.stone(a)gmail.com&gt; writes: 
CS> I have some php-pear packages which specifically indicate they
CS> need php >= 4.2.0 some that say they need php >= 4.3.0.  If these
CS> versions are specified by the package, they should be indicated in
CS> the spec file (IMO).

I'm not sure I agree; Perl and Python modules will require the version
of Perl or Python that was installed when the package was built (via
perl(:MODULE_COMPAT_blah) or python-abi); it is certainly simpler to 
figure it out automatically instead of leaving it to the packager to
try and specify something which may be essentially meaningless.  But
on the other hand, of core updates the PHP package, we don't want
modules automatically forcing a core PHP package update.  So I guess
I'm undecided.

CS> Note pear and pecl modules both need to get path infomation in the
CS> same way:

Doesn't look the same to me; one calls "pear", the other calls
"pecl".  Are you saying that those two directories will always be
identical even though two different programs are called to figure that
out?

[Smarty]
CS> If there is something wrong with installing it in
CS> %_datadir, where should it go instead?

Well, thankfully every Perl and Python class library doesn't go in
%_datadir; we'd have thousands and thousands of directories there.
Why not some PHP-specific place?

CS> How is this different than: Requires(post): php-pear

We don't use Requires(post): glibc when we want to call
/sbin/ldconfig.

[ || : bits]
CS> Why are these no longer wanted?  First I am told to put them in, and
CS> now I am told not to.

I was asked to remove them and told they were no longer necessary for
one of my packages, but now I can't find it where that was.  (I think
it was the denyhosts review, but that ticket seems to be missing from
bugzilla completely for whatever reason.)

Honestly I don't fully understand the issue so don't take what I wrote
as the way things have to be.

 - J<

[Paul Howarth]

On Tue, 2006-07-04 at 14:43 -0500, Jason L Tibbitts III wrote:
>  >>>>> "CS" == Christopher Stone
> <chris.stone(a)gmail.com&gt; writes:
>  [ || : bits]
>  CS> Why are these no longer wanted?  First I am told to put them in, and
>  CS> now I am told not to.
>  
>  I was asked to remove them and told they were no longer necessary for
>  one of my packages, but now I can't find it where that was.  (I think
>  it was the denyhosts review, but that ticket seems to be missing from
>  bugzilla completely for whatever reason.)
>  
>  Honestly I don't fully understand the issue so don't take what I wrote
>  as the way things have to be. 
One of the scriptlets in question was:

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

I'll speculate that the --ignore-errors option means that pear will
never return a non-zero exit status and hence the "|| :" is not needed
to ensure that the scriptlet always "succeeds".

Paul.

[Christopher Stone]

On 7/4/06, Paul Howarth <paul(a)city-fan.org&gt; wrote:
>  On Tue, 2006-07-04 at 14:43 -0500, Jason L Tibbitts III wrote:
>  > >>>>> "CS" == Christopher Stone
> <chris.stone(a)gmail.com&gt; writes:
>  > [ || : bits]
>  > CS> Why are these no longer wanted?  First I am told to put them in, and
>  > CS> now I am told not to.
>  >
>  > I was asked to remove them and told they were no longer necessary for
>  > one of my packages, but now I can't find it where that was.  (I think
>  > it was the denyhosts review, but that ticket seems to be missing from
>  > bugzilla completely for whatever reason.)
>  >
>  > Honestly I don't fully understand the issue so don't take what I wrote
>  > as the way things have to be.
>
>  One of the scriptlets in question was:
>
>  %postun
>  if [ "$1" -eq "0" ]; then
>      /usr/bin/pear uninstall --nodeps --ignore-errors --register-only \
>          PEAR_Command_Packaging >/dev/null
>  fi
>
>  I'll speculate that the --ignore-errors option means that pear will
>  never return a non-zero exit status and hence the "|| :" is not needed
>  to ensure that the scriptlet always "succeeds". 
I supposed there is always a chance a buggy pear breaks the
--ignore-errors option, if someone has a hosed system and php
segfaults, will this also not be an issue, not sure if a segfault or
something constitutes an error being returned?  I kind of feel safer
keeping it there for insurance, but if there is a consensus to remove
it, that is fine with me.

[Tim Jackson]

Jason L Tibbitts III wrote:
> >>>>> "CS" == Christopher Stone
> <chris.stone(a)gmail.com&gt; writes:
>  
>  CS> I have some php-pear packages which specifically indicate they
>  CS> need php >= 4.2.0 some that say they need php >= 4.3.0.  If these
>  CS> versions are specified by the package, they should be indicated in
>  CS> the spec file (IMO).
>  
>  I'm not sure I agree; Perl and Python modules will require the version
>  of Perl or Python that was installed when the package was built (via
>  perl(:MODULE_COMPAT_blah) or python-abi); it is certainly simpler to 
>  figure it out automatically instead of leaving it to the packager to
>  try and specify something which may be essentially meaningless.  But
>  on the other hand, of core updates the PHP package, we don't want
>  modules automatically forcing a core PHP package update.  So I guess
>  I'm undecided. 
If it's any help, the authors of many PEAR/PECL packages specify 
explicit versions via the package.xml file included with the tarball. 
In this case I think we should just go with what upstream specify as 
they're by far the best placed to judge.

NB that at least for specs generated via PEAR_Command_Packaging, this 
stuff will happen automatically; the specified version (if any) in 
package.xml will be translated into an RPM Requires:.

Tim

[Christopher Stone]

BTW, I have updated my pear spec template
http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec to
%ghost %{peardir}/.* rather than rm'ing them during the install.

[Christopher Stone]

On 7/4/06, Christopher Stone <chris.stone(a)gmail.com&gt; wrote:
>  BTW, I have updated my pear spec template
>  http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec to
>  %ghost %{peardir}/.* rather than rm'ing them during the install. 
%exclude might be better here, I think %ghost might try to remove them
on uninstall, but I'm not sure why pear puts them there to begin with?
 Either way, I think those files should be in either %exclude or
%ghost rather than rm'd during the install process.

[Tim Jackson]

Christopher Stone wrote:
>  On 7/4/06, Christopher Stone <chris.stone(a)gmail.com&gt; wrote:
> > BTW, I have updated my pear spec template
> > http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec to
> > %ghost %{peardir}/.* rather than rm'ing them during the install.
>  
>  %exclude might be better here, I think %ghost might try to remove them
>  on uninstall, but I'm not sure why pear puts them there to begin with? 
Because when we do stuff in RPM build roots, PEAR has nowhere to write 
its package data (e.g. list of installed packages) so it sets up all 
those files. They are not needed in any way.

Arguably the --packagingroot option should omit the generation of these 
files full stop. Might be worth discussing upstream.

>  Either way, I think those files should be in either %exclude or
>  %ghost rather than rm'd during the install process. 
I'm not sure what difference it makes whether they are rm'd or excluded. 
They certainly don't want to be %ghost.

Tim

[Christopher Stone]

On 7/4/06, Tim Jackson <lists(a)timj.co.uk&gt; wrote:
>  Christopher Stone wrote:
>  > On 7/4/06, Christopher Stone <chris.stone(a)gmail.com&gt; wrote:
>  >> BTW, I have updated my pear spec template
>  >> http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec to
>  >> %ghost %{peardir}/.* rather than rm'ing them during the install.
>  >
>  > %exclude might be better here, I think %ghost might try to remove them
>  > on uninstall, but I'm not sure why pear puts them there to begin with?
>
>  Because when we do stuff in RPM build roots, PEAR has nowhere to write
>  its package data (e.g. list of installed packages) so it sets up all
>  those files. They are not needed in any way.
>
>  Arguably the --packagingroot option should omit the generation of these
>  files full stop. Might be worth discussing upstream. 
Yes, please, we should not have to deal with this in every single pear
spec file.

>  > Either way, I think those files should be in either %exclude or
>  > %ghost rather than rm'd during the install process.
>
>  I'm not sure what difference it makes whether they are rm'd or excluded.
>  They certainly don't want to be %ghost. 
I'll change the spec to %exclude and then we can just remove that once
upstream fixes pear/pecl commands from generating those files.

[Ville Skyttä]

On Tue, 2006-07-04 at 16:00 -0700, Christopher Stone wrote:
>  On 7/4/06, Tim Jackson <lists(a)timj.co.uk&gt; wrote:
>  >
>  > I'm not sure what difference it makes whether they are rm'd or excluded.
>  > They certainly don't want to be %ghost.
>  
>  I'll change the spec to %exclude and then we can just remove that once
>  upstream fixes pear/pecl commands from generating those files. 
Using "rm -f" in %install is more flexible than %exclude because it
doesn't actually require those files to be present; it would work both
now and in the future thus possibly avoiding some specfile forks between
distro versions, and would avoid the issue (well, probably a non-issue
in this particular case) with %exclude and rpm size calculations:
https://bugzilla.redhat.com/89661

[Christopher Stone]

On 7/4/06, Tim Jackson <lists(a)timj.co.uk&gt; wrote:
>  Arguably the --packagingroot option should omit the generation of
> these
>  files full stop. Might be worth discussing upstream. 
One could also argue that installing the package.xml file into a
standard PHP defined location could also be done with --packagingroot
to allow for installers such as rpm to properly register and
unregister the packages.  This would allow us to remove more "cruft"
from the spec files.

[Christopher Stone]

On 7/4/06, Jason L Tibbitts III <tibbs(a)math.uh.edu&gt; wrote:
>  >>>>> "CS" == Christopher Stone
> <chris.stone(a)gmail.com&gt; writes:
>  CS> Note pear and pecl modules both need to get path infomation in the
>  CS> same way:
>
>  Doesn't look the same to me; one calls "pear", the other calls
>  "pecl".  Are you saying that those two directories will always be
>  identical even though two different programs are called to figure that
>  out? 
I meant they get the information in the same way, yes.  Basically the
only difference is one uses the pear command and one uses the pecl
command.


>  [Smarty]
>  CS> If there is something wrong with installing it in
>  CS> %_datadir, where should it go instead?
>
>  Well, thankfully every Perl and Python class library doesn't go in
>  %_datadir; we'd have thousands and thousands of directories there.
>  Why not some PHP-specific place? 
/usr/share/php/Smarty is definately smarter ;-)


>  CS> How is this different than: Requires(post): php-pear
>
>  We don't use Requires(post): glibc when we want to call
>  /sbin/ldconfig.
>  
I have updated the template spec file here:
http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec

I am assuming that the php-pear package drops in the %{__pear} and
%{__pecl} macros as suggested by Nicolas.

>  [ || : bits]
>  CS> Why are these no longer wanted?  First I am told to put them in, and
>  CS> now I am told not to.
>
>  I was asked to remove them and told they were no longer necessary for
>  one of my packages, but now I can't find it where that was.  (I think
>  it was the denyhosts review, but that ticket seems to be missing from
>  bugzilla completely for whatever reason.)
>
>  Honestly I don't fully understand the issue so don't take what I wrote
>  as the way things have to be. 
I have left these in for now, rather be safe than sorry.

[Christopher Stone]

On 7/4/06, Christopher Stone <chris.stone(a)gmail.com&gt; wrote:
>  I am assuming that the php-pear package drops in the %{__pear} and
>  %{__pecl} macros as suggested by Nicolas. 
Actually if the php-pear package does this, the php-pear package
should also define all these macros:

%{!?__pear: %define __pear /usr/bin/pear}
%{!?__pecl: %define __pecl /usr/bin/pecl}
%define pear_phpdir  %(%{__pear} config-get php_dir  2> /dev/null ||
echo undefined)
%define pear_docdir  %(%{__pear} config-get doc_dir  2> /dev/null ||
echo undefined)
%define pear_testdir %(%{__pear} config-get test_dir 2> /dev/null ||
echo undefined)
%define pear_testdir %(%{__pear} config-get data_dir 2> /dev/null ||
echo undefined)
%define pear_xmldir  %{pear_phpdir}/.pkgxml
%define pecl_phpdir  %(%{__pecl} config-get php_dir  2> /dev/null ||
echo undefined)
%define pecl_docdir  %(%{__pecl} config-get doc_dir  2> /dev/null ||
echo undefined)
%define pecl_testdir %(%{__pecl} config-get test_dir 2> /dev/null ||
echo undefined)
%define pecl_testdir %(%{__pecl} config-get data_dir 2> /dev/null ||
echo undefined)
%define pecl_xmldir  %{pecl_phpdir}/.pkgxml

[Christopher Stone]

On 7/4/06, Christopher Stone <chris.stone(a)gmail.com&gt; wrote:
>  %define pear_testdir %(%{__pear} config-get test_dir 2> /dev/null
> ||
>  echo undefined)
>  %define pear_testdir %(%{__pear} config-get data_dir 2> /dev/null ||
>  echo undefined) 
Just noticed that the 2nd one should be data_dir.  I have updated my spec file:
http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec
So that it no longer defines these macros (spec file is starting to
look pretty simple now)

I can put the macros back, but updating the php-pear package should be
easy if that is a possibility.

[Orion Poplawski]

Christopher Stone wrote:
>  On 7/4/06, Jason L Tibbitts III <tibbs(a)math.uh.edu&gt; wrote:
> > >>>>> "CS" == Christopher Stone
> <chris.stone(a)gmail.com&gt; writes:
>  
> > [Smarty]
> > CS> If there is something wrong with installing it in
> > CS> %_datadir, where should it go instead?
> >
> > Well, thankfully every Perl and Python class library doesn't go in
> > %_datadir; we'd have thousands and thousands of directories there.
> > Why not some PHP-specific place?
>  
>  /usr/share/php/Smarty is definately smarter ;-)
>   
Will php own /usr/share/php ?

-- 
Orion Poplawski
System Administrator                   303-415-9701 x222
Colorado Research Associates/NWRA      FAX: [phone]
3380 Mitchell Lane, Boulder CO 80301   http://www.co-ra.com

[Enrico Scholz]

chris.stone(a)gmail.com ("Christopher Stone") writes:

>  Packages which are .php files only such as php-Smarty or
> php-pear-Foo
>  need only require php >= version they say they require, or if they do
>  not say, then php >= current version (or no version) should be fine.
>  I have some php-pear packages which specifically indicate they need
>  php >= 4.2.0 some that say they need php >= 4.3.0. 
Such Requires: do not make sense nowadays. The ability to require a
special program version was removed some time ago from rpm.

Now, you can require a special package version only and every PHP in
the supported Fedora Extras branches fulfills the requirements. Since
packaging guidelines are tending to minimize the explicitly written
(Build)Requires:, such unneeded versions should be removed too.



Enrico

[Jason L Tibbitts III]

> >>>> "ES" == Enrico Scholz
> <enrico.scholz(a)informatik.tu-chemnitz.de&gt; writes: 
ES> Such Requires: do not make sense nowadays. The ability to require
ES> a special program version was removed some time ago from rpm.

Unfortunately I can't quite parse what Enrico has written here; it
looks like that statement indicates that versioned requirements don't
work in RPM, which I don't think is the case.

Enrico, could you (or anyone else who understands the issue) elaborate
a bit?

 - J<

[Enrico Scholz]

tibbs(a)math.uh.edu (Jason L Tibbitts III) writes:

>  ES> Such Requires: do not make sense nowadays. The ability to
> require
>  ES> a special program version was removed some time ago from rpm.
>
>  Unfortunately I can't quite parse what Enrico has written here; it
>  looks like that statement indicates that versioned requirements don't
>  work in RPM, which I don't think is the case.
>
>  Enrico, could you (or anyone else who understands the issue) elaborate
>  a bit? 
Some years ago, you could write

| Requires: foo > 2.1

which would be fulfilled by foo=0:2.1 but not by foo=42:1.0.


Then, rpm was changed to interprete the statement above as

| Requires: foo > 0:2.1

So, program version 1.0 packaged with an epoch of '42' would be allowed.

Therefore, versioned requirements make sense in a special environment
only where you exactly know possible EVR values.



Enrico

[Christopher Stone]

On 7/5/06, Enrico Scholz <enrico.scholz(a)informatik.tu-chemnitz.de&gt; wrote:
>  tibbs(a)math.uh.edu (Jason L Tibbitts III) writes:
>
>  > ES> Such Requires: do not make sense nowadays. The ability to require
>  > ES> a special program version was removed some time ago from rpm.
>  >
>  > Unfortunately I can't quite parse what Enrico has written here; it
>  > looks like that statement indicates that versioned requirements don't
>  > work in RPM, which I don't think is the case.
>  >
>  > Enrico, could you (or anyone else who understands the issue) elaborate
>  > a bit?
>
>  Some years ago, you could write
>
>  | Requires: foo > 2.1
>
>  which would be fulfilled by foo=0:2.1 but not by foo=42:1.0.
>
>
>  Then, rpm was changed to interprete the statement above as
>
>  | Requires: foo > 0:2.1
>
>  So, program version 1.0 packaged with an epoch of '42' would be allowed.
>
>  Therefore, versioned requirements make sense in a special environment
>  only where you exactly know possible EVR values. 
Okay, now I'm _really_ confused.  So you are saying rpm can handle
epochs properly now?  That's great, so why should we remove version
requirements from our spec files now that rpm properly handles epochs?

[Rex Dieter]

Christopher Stone wrote:

>  rpm can handle epochs properly now?  
Yes.

>  That's great, so why should we remove version
>  requirements from our spec files now that rpm properly handles epochs? 
IMO, you shouldn't.

-- Rex

[Enrico Scholz]

chris.stone(a)gmail.com ("Christopher Stone") writes:

> > > ES> Such Requires: do not make sense nowadays. The
> ability to require
> > > ES> a special program version was removed some time ago from rpm.
> > >
> > > Unfortunately I can't quite parse what Enrico has written here; it
> > > looks like that statement indicates that versioned requirements don't
> > > work in RPM, which I don't think is the case.
> > >
> > > Enrico, could you (or anyone else who understands the issue) elaborate
> > > a bit?
> > ...
>  Okay, now I'm _really_ confused.  So you are saying rpm can handle
>  epochs properly now? 
No


>  That's great, so why should we remove version requirements from
> our
>  spec files now that rpm properly handles epochs? 
Ok; a more realistic example: you have an application for Fedora
Extras which requires bind, version 9.3 or later.  What would you
write?

a) Requires: bind >= 9.3?
b) Requires: bind >= 24:9.3?

When your answer is a): this requirement would be fulfilled by FE3 with
its bind 9.2.1 too, so this answer would be wrong.

When your answer is b): what would you gain with it? Epochs are a
per-environment thing and not bound to program versions. E.g. SuSE or
Mandriva might have bind-1:9.4 packages. Because the Fedora Extras
packages are for a specific environment (FE4, FE5, devel) only, you
can be sure that the needed program versions are available there and
the explicit version is not needed.




Enrico

[Christopher Stone]

On 7/5/06, Enrico Scholz <enrico.scholz(a)informatik.tu-chemnitz.de&gt; wrote:
>  Ok; a more realistic example: you have an application for Fedora
>  Extras which requires bind, version 9.3 or later.  What would you
>  write?
>
>  a) Requires: bind >= 9.3?
>  b) Requires: bind >= 24:9.3?
>
>  When your answer is a): this requirement would be fulfilled by FE3 with
>  its bind 9.2.1 too, so this answer would be wrong.
>
>  When your answer is b): what would you gain with it? Epochs are a
>  per-environment thing and not bound to program versions. E.g. SuSE or
>  Mandriva might have bind-1:9.4 packages. Because the Fedora Extras
>  packages are for a specific environment (FE4, FE5, devel) only, you
>  can be sure that the needed program versions are available there and
>  the explicit version is not needed. 
The answer is a.  If it doesn't work on FE3 then I would be surprised,
and it should be fixed by the legacy team for FE3.

Why would you ever use b?  I think you might be confused on the
versioning, you do realize that a version of 9:3 is different than a
version of 9.3 correct?

[Enrico Scholz]

chris.stone(a)gmail.com ("Christopher Stone") writes:

>  On 7/5/06, Enrico Scholz
> <enrico.scholz(a)informatik.tu-chemnitz.de&gt; wrote:
> > Ok; a more realistic example: you have an application for Fedora
> > Extras which requires bind, version 9.3 or later.  What would you
> > write?
> >
> > a) Requires: bind >= 9.3?
> >
> > When your answer is a): this requirement would be fulfilled by FE3 with
> > its bind 9.2.1 too, so this answer would be wrong.
>  ...
>  The answer is a.  If it doesn't work on FE3 then I would be surprised,
>  and it should be fixed by the legacy team for FE3. 
This application can not work in FE3 because it requires bind, version
9.3 but FE3 has 9.2.4 only (the 9.2.1 above was wrong; sorry).

With current rpm you can express package (but not version) dependencies
only. Therefore, the Requires: above would be fulfilled in FE3 because it
has bind-20:9.2.4 which is newer than bind-9.3 (which will be interpreted
as bind-0:9.3 nowadays).



Enrico

[Christopher Stone]

On 7/5/06, Enrico Scholz <enrico.scholz(a)informatik.tu-chemnitz.de&gt; wrote:
>  With current rpm you can express package (but not version)
> dependencies
>  only. Therefore, the Requires: above would be fulfilled in FE3 because it
>  has bind-20:9.2.4 which is newer than bind-9.3 (which will be interpreted
>  as bind-0:9.3 nowadays). 
This must be a special case because packages are not meant to go from
a higher epoch to a lower one.  We should not change every single spec
file just because one package does things incorrectly so we can
support a deprecated distro.

[Paul Howarth]

On Wed, 2006-07-05 at 12:10 -0700, Christopher Stone wrote:
>  On 7/5/06, Enrico Scholz
> <enrico.scholz(a)informatik.tu-chemnitz.de&gt; wrote:
>  > With current rpm you can express package (but not version) dependencies
>  > only. Therefore, the Requires: above would be fulfilled in FE3 because it
>  > has bind-20:9.2.4 which is newer than bind-9.3 (which will be interpreted
>  > as bind-0:9.3 nowadays).
>  
>  This must be a special case because packages are not meant to go from
>  a higher epoch to a lower one.  We should not change every single spec
>  file just because one package does things incorrectly so we can
>  support a deprecated distro. 
The only thing done incorrectly was having the:

Requires: bind >= 9.3

which, as Enrico said, was meaningless due to bind's use of epochs.

The bind package itself has used epochs in the correct ascending order
and has not done things incorrectly (other than use epochs at all, one
might say).

Paul.

[Christopher Stone]

On 7/5/06, Paul Howarth <paul(a)city-fan.org&gt; wrote:
>  On Wed, 2006-07-05 at 12:10 -0700, Christopher Stone wrote:
>  > On 7/5/06, Enrico Scholz <enrico.scholz(a)informatik.tu-chemnitz.de&gt; wrote:
>  > > With current rpm you can express package (but not version) dependencies
>  > > only. Therefore, the Requires: above would be fulfilled in FE3 because it
>  > > has bind-20:9.2.4 which is newer than bind-9.3 (which will be interpreted
>  > > as bind-0:9.3 nowadays).
>  >
>  > This must be a special case because packages are not meant to go from
>  > a higher epoch to a lower one.  We should not change every single spec
>  > file just because one package does things incorrectly so we can
>  > support a deprecated distro.
>
>  The only thing done incorrectly was having the:
>
>  Requires: bind >= 9.3
>
>  which, as Enrico said, was meaningless due to bind's use of epochs.
>
>  The bind package itself has used epochs in the correct ascending order
>  and has not done things incorrectly (other than use epochs at all, one
>  might say). 
oops I'm sorry, bind uses an epoch of 30 for FE5 these days, Enrico
said it used an epoch of 0 today (or that is how I intrepreted his
message).

So I am not really sure with how bind versioning numbers work and why
it's epoch is increased so much, but for a Fedora package you should
specify the epoch with bind to ensure the proper version.

If you want to make your spec file work with other distros you would
have to do something like:

%if 0%{?suse_version}
Requires:  bind >= 0:9.3 (or whatever epoch suse uses)
%else
Requires: bind >= 30:9.3
%endif

[Enrico Scholz]

chris.stone(a)gmail.com ("Christopher Stone") writes:

>  oops I'm sorry, bind uses an epoch of 30 for FE5 these days,
> Enrico
>  said it used an epoch of 0 today (or that is how I intrepreted his
>  message). 
Complete posting/subthread was about the

| Requires: bind >= 9.3

I never said that the bind-30:9.3.2-20 package from FC5 would be
interpreted as an epoch 0.

'Today' means current rpm; previous rpm version tried to add an implicit
epoch when an epoch'ed and a non-epoch'ed package were compared. With
previous rpm versions, the 'Requires:' above would be _read_ as

| Requires: bind >= [30:]9.3

when _compared_ with bind-30:9.3.2-20 or as

| Requires: bind >= [20:]9.2.4

when _compared_ with bind-20:9.2.4-2.


But this implementation was buggy and stored the implicit epoch in
the rpm database when package was updated (afair) which was causing
lot of problems. Algorithm was replaced by a missing-epoch == epoch-0
assumption.



>  Requires: bind >= 30:9.3 
ok; now we are back at

> >>>>> b) Requires: bind >= 24:9.3?
> >>>>> ...
> >>>>> When your answer is b): what would you gain with it?... 



Enrico

[Paul Howarth]

On Wed, 2006-07-05 at 11:53 -0700, Christopher Stone wrote:
>  On 7/5/06, Enrico Scholz
> <enrico.scholz(a)informatik.tu-chemnitz.de&gt; wrote:
>  > Ok; a more realistic example: you have an application for Fedora
>  > Extras which requires bind, version 9.3 or later.  What would you
>  > write?
>  >
>  > a) Requires: bind >= 9.3?
>  > b) Requires: bind >= 24:9.3?
>  >
>  > When your answer is a): this requirement would be fulfilled by FE3 with
>  > its bind 9.2.1 too, so this answer would be wrong.
>  >
>  > When your answer is b): what would you gain with it? Epochs are a
>  > per-environment thing and not bound to program versions. E.g. SuSE or
>  > Mandriva might have bind-1:9.4 packages. Because the Fedora Extras
>  > packages are for a specific environment (FE4, FE5, devel) only, you
>  > can be sure that the needed program versions are available there and
>  > the explicit version is not needed.
>  
>  The answer is a.  If it doesn't work on FE3 then I would be surprised,
>  and it should be fixed by the legacy team for FE3. 
Supposing the latest FC3 bind package is 20:9.2.4 (I'll trust Enrico on
that). To the best of my knowledge there is no security or serious bug
in that version and therefore nothing for the Legacy team to concern
themselves with.

As far as rpm is concerned, version 20:9.2.4 is newer than version 9.3
(i.e. 0:9.3) and hence would satisfy a dependency of:

Requires: bind >= 9.3

However, the pacakge using this would not build/work because it actually
requires version 9.3 or later, which version 9.2.4 is not.

>  Why would you ever use b? 
To make sure that the problem just described did not happen.

>  I think you might be confused on the
>  versioning, you do realize that a version of 9:3 is different than a
>  version of 9.3 correct? 
Who said anything about 9:3?

Paul.

[Ville Skyttä]

On Wed, 2006-07-05 at 20:39 +0200, Enrico Scholz wrote:

>  Because the Fedora Extras
>  packages are for a specific environment (FE4, FE5, devel) only, you
>  can be sure that the needed program versions are available there and
>  the explicit version is not needed. 
And because the intended environment is known, we'd know what Epochs to
use.  The way I look at it, versioned dependencies still have some nice
to have uses, in no particular order (and not implying that support for
these cases should be mandated):

- They serve as a favour to those who try to rebuild and then use such
packages on earlier distro versions than what they're shipped for or
maintained in FE.  For example, although I stick with FC5 at the moment,
I have cherry picked and rebuilt a few things locally from Rawhide and
FE devel, which is helpful when maintaining and testing my packages in
devel.  Another example would be people who are stuck with an old FC
version but would like to locally rebuild something which is available
only in newer FE branches.

- Ditto to those who do that on sufficiently compatible (as in
derivative/"sister" distros) such as RHEL and friends, Aurora etc.

- Package versions in FC do get upgraded during the lifetime of a
version, and some package may require a version of something that was
not sufficiently new in the baseline FC install media but is only
available in updates for that version.  Although in practice the window
may be small and there may be other problems with doing it, omitting the
version can bite people who upgrade from an earlier distro version to
the baseline of the newer one (eg. using install media) instead of going
straight to baseline+updates.

[Enrico Scholz]

ville.skytta(a)iki.fi (Ville Skyttä) writes:

> > Because the Fedora Extras packages are for a specific
> environment
> > (FE4, FE5, devel) only, you can be sure that the needed program
> > versions are available there and the explicit version is not needed.
>
>  And because the intended environment is known, we'd know what Epochs to
>  use.  The way I look at it, versioned dependencies still have some nice
>  to have uses, in no particular order (and not implying that support for
>  these cases should be mandated): 
* there are already complains about redundant dependencies when

  | BuildRequires: A-devel B-devel

  is used and an A-devel -> B-devel chain exists (most of your arguments
  apply to this situation too). Why should redundant information like

  | Requires: C >= EVR

  handled in another way?


* I do not say that versioned dependency shall be forbidden; they just
  do not make sense and I am against a rule like

  | I have some php-pear packages which specifically indicate they need
  | php >= 4.2.0 some that say they need php >= 4.3.0.  If these versions
  | are specified by the package, they should be indicated in the spec
  | file (IMO).

  which was requested in the first posting replied by me.




Enrico

[Ville Skyttä]

On Wed, 2006-07-05 at 22:09 +0200, Enrico Scholz wrote:

>  * there are already complains about redundant dependencies when
>    | BuildRequires: A-devel B-devel
>    is used and an A-devel -> B-devel chain exists 
Getting a bit off topic, but if they're *really* redundant, there's
nothing wrong with such complaints.  However, in some cases, the
complaints are not much more than fragile and more or less misinformed
attempts to optimize/minimize things written specfiles.

When both A-devel and B-devel are directly and independently used,
there's nothing wrong with explicitly requiring both, no matter if a dep
chain exists between them or not.  However, if a direct dependency on
B-devel is inflicted some way by A-devel and the thing to be built
wouldn't "naturally" need B-devel otherwise, it can be argued that an
explicit dependency on B-devel is subject to bitrot and would be better
left out if BR: A-devel is there and A-devel pulls in B-devel.

>  Why should redundant information like
>    | Requires: C >= EVR 
Mileages vary whether the version is redundant or not.  The worst thing
that can happen is that it becomes outdated and thus useless if the
packager doesn't bother to track it.  But when kept up to date, it will
help in cases such as those from my previous mail.

>  * I do not say that versioned dependency shall be forbidden; they
> just
>    do not make sense and I am against a rule like
>  
>    | I have some php-pear packages which specifically indicate they need
>    | php >= 4.2.0 some that say they need php >= 4.3.0.  If these versions
>    | are specified by the package, they should be indicated in the spec
>    | file (IMO). 
I tend to agree with the original poster.

[Enrico Scholz]

ville.skytta(a)iki.fi (Ville Skyttä) writes:

> > Why should redundant information like
> >   | Requires: C >= EVR
>
>  Mileages vary whether the version is redundant or not. 
No; when you submit a package for FE with

| Requires: php >= 4.2.0

then the '>= 4.2.0' is redundant because every FE has a php >= 4.2.0 and

| Requires: php

suffices there.



Enrico

[Jason L Tibbitts III]

> >>>> "ES" == Enrico Scholz
> <enrico.scholz(a)informatik.tu-chemnitz.de&gt; writes: 
ES> then the '>= 4.2.0' is redundant because every FE has a php >=
ES> 4.2.0 and

Now that I can understand, but I don't think it's reasonable for
package submitters and reviewers to know the full version history of
package in Core and Extras.  We have to do this on occasion with Perl
package dependencies because you will have to filter out the
unversioned dependency RPM will find if you want to include a
versioned one, and it's always a pain.

I think it reasonable to say that the version is optional if it would
always be satisfied in any of the targeted Fedora releases.

 - J<

[Jason L Tibbitts III]

> >>>> "ES" == Enrico Scholz
> <enrico.scholz(a)informatik.tu-chemnitz.de&gt; writes: 
ES> * I do not say that versioned dependency shall be forbidden; they
ES> just do not make sense and I am against a rule like

This makes no sense to me.  So if Red Hat bumps the FC5 PHP from 5.1.4
to 5.1.5 to fix some bug and a package requires that fixed version,
what is it supposed to require?  How else do you express a dependency
on a a particular version other than through a versioned dependency?

 - J<

[Enrico Scholz]

tibbs(a)math.uh.edu (Jason L Tibbitts III) writes:

>  ES> * I do not say that versioned dependency shall be forbidden;
> they
>  ES> just do not make sense and I am against a rule like
>      | If these versions are specified by the package, they should be 
>      | indicated in the spec file (IMO).
>
>  This makes no sense to me.  So if Red Hat bumps the FC5 PHP from 5.1.4
>  to 5.1.5 to fix some bug and a package requires that fixed version,
>  what is it supposed to require? 
In this case you you will have to use a versioned dependency but this is
different from "specified by the package".

E.g. when php-5.1.4-1 has a bug which will be fixed by a patch (which
fixes only this issue without a full version upgrade) you have to write

| Requires: php >= 5.1.4-2

and can not follow README which says that 5.1.5 will be required.


The version in the Requires: depends on the environment but not on the
requirement told by the (upstream) package.

In the discussed case, the version in "php >= 4.2.0" is redundant in FE
environments and except for 3rd party repository-support there is no
reason to use it resp. to enforce it.




Enrico

[Nicolas Mailhot]

Le mercredi 05 juillet 2006 à 22:09 +0200, Enrico Scholz a écrit :
>  ville.skytta(a)iki.fi (Ville Skyttä) writes:
>  
>  >> Because the Fedora Extras packages are for a specific environment
>  >> (FE4, FE5, devel) only, you can be sure that the needed program
>  >> versions are available there and the explicit version is not needed. 
This is totally wrong.

When you package for FCx, and one of your deps got a major version bump
in FCx updates, what do you target ? FCx as it was released of FCx after
all updates are applied ? How do you tell the package manager when your
package is safe to use ? (this is actually worse for 3rd party
repositories which target 5-years-long RHEL)

Also note that since the project allows parallel updates in all FE
releases (instead of freezing everything but devel),depending on the yum
invocation order people will have vastly different package versions on
their systems (within a single FE release). Not dangerous for people who
do daily broadband pulls. But deadly for systems only used every
few/weeks, and synced every few months (think computer at your grandma
or vacation house, small server only updated when there is a problem,
etc)

Unversionned deps, when you know at which version boundary your package
breaks, is just playing with fire.

-- 
Nicolas Mailhot

[Enrico Scholz]

nicolas.mailhot(a)laposte.net (Nicolas Mailhot) writes:

> > >> Because the Fedora Extras packages are for a specific
> environment
> > >> (FE4, FE5, devel) only, you can be sure that the needed program
> > >> versions are available there and the explicit version is not
> > >> needed.
>
>  This is totally wrong.
>
>  When you package for FCx, and one of your deps got a major version bump
>  in FCx updates, 
major version bumps are impossible for most packages because it would
destroy API compatibility.

When you really *need* a certain *package* version, then you can add a
versioned dependeny. But this version should not be related to something
written in a README but to the current environment. Versioned
dependencies should be checked after some time (1 year for FE) whether
it become redundant in the meantime and be removed if so.


>  Unversionned deps, when you know at which version boundary your
> package
>  breaks, is just playing with fire. 
It is stupid and in most times redundant to add blindly a versioned
dependency just because a README tells that a certain version is
required.




Enrico

[Christopher Stone]

On 7/5/06, Enrico Scholz <enrico.scholz(a)informatik.tu-chemnitz.de&gt; wrote:
>  It is stupid and in most times redundant to add blindly a versioned
>  dependency just because a README tells that a certain version is
>  required. 
pear packages adhere to very strict standards and versioning
requirements is part of that.  All pear packages are very specific
about versioning requirements.  There is even a built in option in the
pear command to list out these requirements which will probably be
used by the php-pear-PEAR-Command-Packaging package.

Please do not ask me to lower the quality standards that pear packages
expect by not providing this information in my spec files.

[Enrico Scholz]

chris.stone(a)gmail.com ("Christopher Stone") writes:

> > It is stupid and in most times redundant to add blindly a
> versioned
> > dependency just because a README tells that a certain version is
> > required.
>
>  pear packages adhere to very strict standards and versioning
>  requirements is part of that.  All pear packages are very specific
>  about versioning requirements. 
Again: rpm does not allow to require a certain program (PHP) version;
you can require a certain package version only.

And btw; packaging guidelines are handling this case already:

  | First, if the lowest possible requirement is so old that nobody has a
  | version older than that installed on any target distribution release,
  | there's no need to include the version in the dependency at all.
  | ...
  | As a rule of thumb, if the version is not required, don't add it just
  | for fun.
    [http://fedoraproject.org/wiki/Packaging/Guidelines]


>  Please do not ask me to lower the quality standards that pear
> packages
>  expect by not providing this information in my spec files. 
You are not lowering quality standards when unneeded and non-working
things like "Requires: php >= 4.2" will be omitted.



Enrico

[Christopher Stone]

On 7/5/06, Enrico Scholz <enrico.scholz(a)informatik.tu-chemnitz.de&gt; wrote:
>  chris.stone(a)gmail.com ("Christopher Stone") writes:
>
>  >> It is stupid and in most times redundant to add blindly a versioned
>  >> dependency just because a README tells that a certain version is
>  >> required.
>  >
>  > pear packages adhere to very strict standards and versioning
>  > requirements is part of that.  All pear packages are very specific
>  > about versioning requirements.
>
>  Again: rpm does not allow to require a certain program (PHP) version;
>  you can require a certain package version only.
>
>  And btw; packaging guidelines are handling this case already:
>
>    | First, if the lowest possible requirement is so old that nobody has a
>    | version older than that installed on any target distribution release,
>    | there's no need to include the version in the dependency at all.
>    | ...
>    | As a rule of thumb, if the version is not required, don't add it just
>    | for fun.
>      [http://fedoraproject.org/wiki/Packaging/Guidelines]
>
>
>  > Please do not ask me to lower the quality standards that pear packages
>  > expect by not providing this information in my spec files.
>
>  You are not lowering quality standards when unneeded and non-working
>  things like "Requires: php >= 4.2" will be omitted. 
Unneeded? by whom? Fedora's rpm? other package maintainers for other
distributions?  Some poor sap who built his OS from scratch who is
trying to determine what he needs installed for your package?  Somone
who only wants to upgrade your package and not their whole system?

Oh I forgot, version dependencies dont work on Fedora (LOL).

We are not adding this information because it's fun, and we are not
adding requirements for packages that are so old nobody will have them
installed.

Can we please close this silly discussion or does anyone here actually
agree with Enrico?

[Enrico Scholz]

chris.stone(a)gmail.com ("Christopher Stone") writes:

> > You are not lowering quality standards when unneeded and
> non-working
> > things like "Requires: php >= 4.2" will be omitted.
>
>  Unneeded? by whom? 
This list contains a 'To: fedora-packaging(a)redhat.com' so I would say
Fedora Extras.

>  Fedora's rpm? 
yes


>  other package maintainers for other distributions? 
dunno; they are not handled by this list.




Enrico

[Christopher Stone]

On 7/6/06, Enrico Scholz <enrico.scholz(a)informatik.tu-chemnitz.de&gt; wrote:
>  chris.stone(a)gmail.com ("Christopher Stone") writes:
>
>  >> You are not lowering quality standards when unneeded and non-working
>  >> things like "Requires: php >= 4.2" will be omitted.
>  >
>  > Unneeded? by whom?
>
>  This list contains a 'To: fedora-packaging(a)redhat.com&#39; so I would say
>  Fedora Extras.
>
>  > Fedora's rpm?
>
>  yes
>
>
>  > other package maintainers for other distributions?
>
>  dunno; they are not handled by this list. 
So we are to just assume everyone will be running a stock Fedora
system then?  In my opinion I think it is better to provide the
information if it is accurate and available as it is with pear
packages.

I don't have the powerz to decide these things but if we must take a
vote on this issue then I will go with whatever the packaging comitte
decides.

[Christopher Stone]

PHP Packaging Guidelines summary:

I have updated my template spec file:
http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec

-Readded the rm dot files and removed the %exclude
-Removed the default group since this is unclear/undecided at best so
I guess it is up to the packager to decide
-Removed the "PEAR:" from the summary line (I don't think we should
require all pear packages to put "PEAR:" in the summary) if anyone
disagrees I can add it back because im not too partial either way.

Questions:
Is using Requires(post):   %{__pear} okay, or do i have to explicitly
say /usr/bin/pear?

What still needs to be resolved:
-Version dependencies on other pear packages, and php core packages,
should it be required as a "must" item, "should" item, or not
mentioned and/or discouraged?
-The php-pear spec file needs to be modified to drop in appropriate
macros for pear and pecl (can a new release of php-pear with this
added be done quickly?)
-Update the php spec file to drop in macros for php_api and
/usr/bin/php (also can this be done quickly?)
-Decide how many different Provides variations we want to provide.
-Provide a /usr/share/php/ directory which is owned by the php package
or something for packages like php-Smarty.

Upstream issues:
- generating dot files and installing xml files should probably be
done automagically by the pear/pecl commands when using
--packagingroot.  These are not critical to our passing guidelines.
- the pecl command doesn't work with --packagingroot or
--register-only, we need to identify bugs and report them to upstream
to be fixed.  This is critical to the pecl guidelines if we want them
to use the (almost) identical spec as the pear packages.  There are
other ways we can build pecl packages so we have to decide if we want
to package pecl packages differently for now until upstream fixes
these bugs.

I *think* this is all the remaining open issues, please let me know if
I have missed something.  I think with a little effort from the php
and php-pear maintainers, and some quick final decisions from the
packaging comittee, we can get guidelines ready for atleast the php-*
and php-pear-* packages and have a php-pear template in use.
php-pecl-* packages still need a default template which depends on
upstream bug fix issues.

[Ralf Corsepius]

On Thu, 2006-07-06 at 01:07 -0700, Christopher Stone wrote:
>  PHP Packaging Guidelines summary:
>  
>  I have updated my template spec file:
>  http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec
>  
>  -Readded the rm dot files and removed the %exclude
>  -Removed the default group since this is unclear/undecided at best so
>  I guess it is up to the packager to decide
>  -Removed the "PEAR:" from the summary line (I don't think we should
>  require all pear packages to put "PEAR:" in the summary) if anyone
>  disagrees I can add it back because im not too partial either way.
>  
>  Questions:
>  Is using Requires(post):   %{__pear} okay, or do i have to explicitly
>  say /usr/bin/pear? 
IMO:

If %{__pear} is _guaranteed_ to be provided and if it expands to a
binary containing an absolute path, yes, this would be fine.

One of these conditions can not be assured, then no, %{__pear} would not
be OK.

Ralf

[Christopher Stone]

On 7/6/06, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Thu, 2006-07-06 at 01:07 -0700, Christopher Stone wrote:
>  > Questions:
>  > Is using Requires(post):   %{__pear} okay, or do i have to explicitly
>  > say /usr/bin/pear?
>  IMO:
>
>  If %{__pear} is _guaranteed_ to be provided and if it expands to a
>  binary containing an absolute path, yes, this would be fine.
>
>  One of these conditions can not be assured, then no, %{__pear} would not
>  be OK. 
So are you saying the %{__pear} macro must be provided by rpm in order
for me to safely use this macro in the Requires line?  If the macro is
provided by php-pear by adding an /etc/rpm/macros.pear file, will this
be okay when building with mock?

[Toshio Kuratomi]

On Wed, 2006-07-05 at 23:58 -0700, Christopher Stone wrote:
>  On 7/5/06, Enrico Scholz
> <enrico.scholz(a)informatik.tu-chemnitz.de&gt; wrote:
>  > Again: rpm does not allow to require a certain program (PHP) version;
>  > you can require a certain package version only.
>  >
>  > And btw; packaging guidelines are handling this case already:
>  >
>  >   | First, if the lowest possible requirement is so old that nobody has a
>  >   | version older than that installed on any target distribution release,
>  >   | there's no need to include the version in the dependency at all.
>  >   | ...
>  >   | As a rule of thumb, if the version is not required, don't add it just
>  >   | for fun.
>  >     [http://fedoraproject.org/wiki/Packaging/Guidelines]
>  >
>  >
>  > > Please do not ask me to lower the quality standards that pear packages
>  > > expect by not providing this information in my spec files.
>  >
>  > You are not lowering quality standards when unneeded and non-working
>  > things like "Requires: php >= 4.2" will be omitted.
>  
>  Unneeded? by whom? Fedora's rpm? other package maintainers for other
>  distributions?  Some poor sap who built his OS from scratch who is
>  trying to determine what he needs installed for your package?  Somone
>  who only wants to upgrade your package and not their whole system?
>  
>  Oh I forgot, version dependencies dont work on Fedora (LOL).
>   
No.  Version dependencies don't work as you're expecting in current rpm.

>  We are not adding this information because it's fun, and we are
> not
>  adding requirements for packages that are so old nobody will have them
>  installed.
>   
You are adding requirements for package versions which are not relevant
for Fedora, which is what the guidelines are saying should be avoided.

>  Can we please close this silly discussion or does anyone here
> actually
>  agree with Enrico? 
Enrico has the following points:
1) rpm's handling of Epochs means that versioned dependencies reference
package versions, not upstream versions.  Because of this, including the
version in the rpm when it is unnecessary for all the distributions we
are supporting is misleading and potentially hurts packagers on other
distributions.

2) Using a versioned dependency pulled verbatim from a README file
ignores the patches applied by the Fedora maintainer to the base
package.  If the README says "Requires php >= 5.0.1 because of a bug in
earlier versions" but the Fedora maintainer has backported fixes to
these bugs for the 5.0-4 package, then using a naive versioned
dependency of Requires: php >= 5.0.1 is wrong.

3) The packaging guidelines already state when it is appropriate to
include versioned dependencies and this is not one of them.  This means
we're deciding whether to make an exception for php/pear packages rather
than making new policy.

The point you seem to be making is that PEAR packages include a lot of
information about the versions of upstream releases that are required.
You'd like to include this in the spec file to help other packagers use
this outside of Fedora.

Currently, I'd be disinclined to make an exception for php/pear
packages.  That could change depending on how compelling the answers to
the following two questions are:

Since PEAR packages provide this dependency information, why should we
include it in the spec file?

Enrico's points 1 & 2 mean that adding version information unnecessarily
can mislead foreign packagers rather than help them.  Why do you think
those points don't apply to PEAR packages?

-Toshio

[Christopher Stone]

On 7/6/06, Toshio Kuratomi <toshio(a)tiki-lounge.com&gt; wrote:
>  On Wed, 2006-07-05 at 23:58 -0700, Christopher Stone wrote:
>  > On 7/5/06, Enrico Scholz <enrico.scholz(a)informatik.tu-chemnitz.de&gt; wrote:
>  > > Again: rpm does not allow to require a certain program (PHP) version;
>  > > you can require a certain package version only.
>  > >
>  > > And btw; packaging guidelines are handling this case already:
>  > >
>  > >   | First, if the lowest possible requirement is so old that nobody has a
>  > >   | version older than that installed on any target distribution release,
>  > >   | there's no need to include the version in the dependency at all.
>  > >   | ...
>  > >   | As a rule of thumb, if the version is not required, don't add it just
>  > >   | for fun.
>  > >     [http://fedoraproject.org/wiki/Packaging/Guidelines]
>  > >
>  > >
>  > > > Please do not ask me to lower the quality standards that pear packages
>  > > > expect by not providing this information in my spec files.
>  > >
>  > > You are not lowering quality standards when unneeded and non-working
>  > > things like "Requires: php >= 4.2" will be omitted.
>  >
>  > Unneeded? by whom? Fedora's rpm? other package maintainers for other
>  > distributions?  Some poor sap who built his OS from scratch who is
>  > trying to determine what he needs installed for your package?  Somone
>  > who only wants to upgrade your package and not their whole system?
>  >
>  > Oh I forgot, version dependencies dont work on Fedora (LOL).
>  >
>  No.  Version dependencies don't work as you're expecting in current rpm.
>
>  > We are not adding this information because it's fun, and we are not
>  > adding requirements for packages that are so old nobody will have them
>  > installed.
>  >
>  You are adding requirements for package versions which are not relevant
>  for Fedora, which is what the guidelines are saying should be avoided. 
How is it not relevant?  If I use FC4 and a pear pacakge I want is on
FC5, should not installing the FC5 package do some version checking or
are we to assume that every fedora user is using only packages from
their distro release?


>  > Can we please close this silly discussion or does anyone here actually
>  > agree with Enrico?
>
>  Enrico has the following points:
>  1) rpm's handling of Epochs means that versioned dependencies reference
>  package versions, not upstream versions.  Because of this, including the
>  version in the rpm when it is unnecessary for all the distributions we
>  are supporting is misleading and potentially hurts packagers on other
>  distributions. 
Yes, but there are no php-pear packages that use epochs and very
likely that none ever will.   Yes, there is a 0.0000000001% chance
that some php-pear package might one day use an epoch.

The argument that version numbers potentially hurt other packagers on
other distributions is ludicris.  The version numbers on pear packages
refer to the upstream versions in 100% of all cases.  Claming that
epochs are going to screw things up for everyone is just silly, it's
not going to happen.

>  2) Using a versioned dependency pulled verbatim from a README file
>  ignores the patches applied by the Fedora maintainer to the base
>  package.  If the README says "Requires php >= 5.0.1 because of a bug in
>  earlier versions" but the Fedora maintainer has backported fixes to
>  these bugs for the 5.0-4 package, then using a naive versioned
>  dependency of Requires: php >= 5.0.1 is wrong. 
Well duh, if you are stupid enough to make a patch to php and not
include the patched version in your requires because the README says
otherwise, then you are too much of an idiot to be packaging for
Fedora to begin with.  Again the "points" being brought up seem more
like "grasping at straws" or "way off topic/off base".

>  3) The packaging guidelines already state when it is appropriate to
>  include versioned dependencies and this is not one of them.  This means
>  we're deciding whether to make an exception for php/pear packages rather
>  than making new policy. 
No. The packaging guidelines indicate when you should NOT use version
numbers specifically saying not to use them if the package they refer
to is older than redhat 6.2 which is pretty old.  Oh and not to add
the just for fun.

Unless there is some other text you are referring to?  We are not
deciding to make an excption to any rules.


>  The point you seem to be making is that PEAR packages include a lot of
>  information about the versions of upstream releases that are required.
>  You'd like to include this in the spec file to help other packagers use
>  this outside of Fedora. 
Or other packagers inside Fedora who do not necessarily have a
pristine standard setup, for example someone with FC5 installed with a
few cherry picked FC6 rpms updated.

>  Currently, I'd be disinclined to make an exception for php/pear
>  packages.  That could change depending on how compelling the answers to
>  the following two questions are: 
WHAT EXCEPTION?!  Please indicate the exact text you are referring to
about this so called "exception".

>  Since PEAR packages provide this dependency information, why should we
>  include it in the spec file? 
Why not?  You havn't convinced me yet that we are going against any
guidelines here.

Why should we include dist tags? Why should we include version numbers
in changelogs?  Why should we add comments in our spec file? etc etc.
(I dont expect you to answer these questions, I just trying to make a
point).

Hell let's just give up any hope of making a good package and change
all Guidelines to read "Just do the minimal amount that is necessary
to make your package work with the version of Fedora which you use".

>  Enrico's points 1 & 2 mean that adding version information unnecessarily
>  can mislead foreign packagers rather than help them.  Why do you think
>  those points don't apply to PEAR packages? 
Because the argument is based off a false premise.  He uses the
argument that since rpm has epoch capabilities, then all version
numbers in all spec files are totally meaningless because epochs are
not used by upstream packages.  Therefore since the bind package uses
epochs we should never use version number requirements in any other
packages especially packages that will most likely never have any need
for the use of the epoch field.  QED.

[Christopher Stone]

On 7/6/06, Christopher Stone <chris.stone(a)gmail.com&gt; wrote:
>  Yes, but there are no php-pear packages that use epochs and very
>  likely that none ever will.   Yes, there is a 0.0000000001% chance
>  that some php-pear package might one day use an epoch. 
Oh and before anyone chimes in saying the php-pear package itself uses
an epoch, I should make the point that we don't use this epoch for
php-pear.  We require php-pear(PEAR) which does not have an epoch in
its version number.  So even in this case we do not use epochs.

[Toshio Kuratomi]

On Thu, 2006-07-06 at 13:42 -0700, Christopher Stone wrote:
>  On 7/6/06, Toshio Kuratomi <toshio(a)tiki-lounge.com&gt; wrote:
>  > You are adding requirements for package versions which are not relevant
>  > for Fedora, which is what the guidelines are saying should be avoided.
>  
>  How is it not relevant?  If I use FC4 and a pear pacakge I want is on
>  FC5, should not installing the FC5 package do some version checking or
>  are we to assume that every fedora user is using only packages from
>  their distro release?
>   
The message that this all stems from is here:
https://www.redhat.com/archives/fedora-packaging/2006-July/msg00050.html
the quotation by you is that you are requiring php >= 4.2.0 in some
packages; php >= 4.3.0 in others.  php 4.3.3 was already present in
Fedora Core 1 so the package version is deeply irrelevant for Fedora.

>  >
>  > 3) The packaging guidelines already state when it is appropriate to
>  > include versioned dependencies and this is not one of them.  This means
>  > we're deciding whether to make an exception for php/pear packages rather
>  > than making new policy.
>  
>  No. The packaging guidelines indicate when you should NOT use version
>  numbers specifically saying not to use them if the package they refer
>  to is older than redhat 6.2 which is pretty old.  Oh and not to add
>  the just for fun.
>  
>  Unless there is some other text you are referring to?  We are not
>  deciding to make an excption to any rules.
>   
I'm sorry, your interpretation of the guideline is wrong.  You're
confusing the example with the rule:
  First, if the lowest possible requirement is so old that nobody has a
  version older than that installed on any target distribution release,
  there's no need to include the version in the dependency at all.  In
  that case we know the available software is new enough. For example,
  the version in gtk+-devel 1.2 dependency above is unnecessary for all
  Red Hat Linux distributions since (at least) release 6.2.

The rule is whether the lowest version requirement is satisfied by the
packages on Fedora's target distributions.  It may be open to
interpretation whether "target distribution release" means non-EOL
distributions (in which case FC4+ currently) or distributions the
packager is actively building for but in either case, php >= 4.2.0 being
irrelevant even for FC1 means it is too old.

Thanks for your well-reasoned rebuttals to Enrico's points.  I'll
continue to read them until I have an opinion on whether putting
unnecessary versions into the package spec is justified.

-Toshio

[Christopher Stone]

On 7/6/06, Toshio Kuratomi <toshio(a)tiki-lounge.com&gt; wrote:
>  On Thu, 2006-07-06 at 13:42 -0700, Christopher Stone wrote:
>  The message that this all stems from is here:
>  https://www.redhat.com/archives/fedora-packaging/2006-July/msg00050.html
>  the quotation by you is that you are requiring php >= 4.2.0 in some
>  packages; php >= 4.3.0 in others.  php 4.3.3 was already present in
>  Fedora Core 1 so the package version is deeply irrelevant for Fedora. 
...
>  The rule is whether the lowest version requirement is satisfied by
> the
>  packages on Fedora's target distributions.  It may be open to
>  interpretation whether "target distribution release" means non-EOL
>  distributions (in which case FC4+ currently) or distributions the
>  packager is actively building for but in either case, php >= 4.2.0 being
>  irrelevant even for FC1 means it is too old. 
I have no problem with just Requiring php instead of php 4.2 because
4.2 is ancient.  Note that even my default spec file:
http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec
Does not have any version number listed for php.  But I do not see any
harm in actually providing this information, it would seem especially
important for packages that require php 5 or even php 6 when it comes
out.

But a really important point I want to make and clarify:
It is not the php version that really concerns me.  It is the version
requirements of other pear packages which is my main concern.

For example, take a look at my spec file for Payment_Process:
http://tkmame.retrogames.com/fedora-extras/php-pear-Payment-Process.spec

This package requires 5 other pear packages with specific version
requirements that have been listed by the package.

Now my questions are:
1) Should I not list the version numbers for these packages just
because these packages never existed in Fedora?
2) Is there any harm in listing the version number requirements?
3) Is there any benefit to not having the version number requirements?

Thanks for keeping an open mind.

[Toshio Kuratomi]

On Thu, 2006-07-06 at 15:11 -0700, Christopher Stone wrote:
>  On 7/6/06, Toshio Kuratomi <toshio(a)tiki-lounge.com&gt; wrote:
>  > On Thu, 2006-07-06 at 13:42 -0700, Christopher Stone wrote:
>  > The message that this all stems from is here:
>  > https://www.redhat.com/archives/fedora-packaging/2006-July/msg00050.html
>  > the quotation by you is that you are requiring php >= 4.2.0 in some
>  > packages; php >= 4.3.0 in others.  php 4.3.3 was already present in
>  > Fedora Core 1 so the package version is deeply irrelevant for Fedora.
>  ...
>  > The rule is whether the lowest version requirement is satisfied by the
>  > packages on Fedora's target distributions.  It may be open to
>  > interpretation whether "target distribution release" means non-EOL
>  > distributions (in which case FC4+ currently) or distributions the
>  > packager is actively building for but in either case, php >= 4.2.0 being
>  > irrelevant even for FC1 means it is too old.
>  
>  I have no problem with just Requiring php instead of php 4.2 because
>  4.2 is ancient.  Note that even my default spec file:
>  http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec
>  Does not have any version number listed for php.  But I do not see any
>  harm in actually providing this information, it would seem especially
>  important for packages that require php 5 or even php 6 when it comes
>  out.
>   
This is a different ball of wax in the beginning but becomes the same
later on.  Let's say FC6 is the first FC to provide php-6.0.1 and your
package requires php-6.0.0.  Then you can list Requires: php >= 6.0.0 in
your spec file.

Now, a year and a half goes by and FC6 goes EOL.  Now the supported
platforms are FC7, FC8, and devel.  All of these platforms have php >=
6.0.0.  So the version information is no longer needed.  I don't know if
you'll get a bug report asking to remove the versioning (probably no one
will notice for quite a while) but new packages should not specify the
Requires: php >= 6.0.0 at that point.

>  But a really important point I want to make and clarify:
>  It is not the php version that really concerns me.  It is the version
>  requirements of other pear packages which is my main concern.
>  
>  For example, take a look at my spec file for Payment_Process:
>  http://tkmame.retrogames.com/fedora-extras/php-pear-Payment-Process.spec
>  
>  This package requires 5 other pear packages with specific version
>  requirements that have been listed by the package.
>  
>  Now my questions are:
>  1) Should I not list the version numbers for these packages just
>  because these packages never existed in Fedora? 
The current guidelines would say,
do not list the version as no Fedora
release ships an unsatisfactory version.  If I wanted to backport the
package to FC4, the first step would be to backport the required
packages from the FE where they exists, as well, so this doesn't seem
like a huge problem.

>  2) Is there any harm in listing the version number requirements?
>  3) Is there any benefit to not having the version number requirements?
>   
This is the crux of the matter.  I still use FC3 on one machine and I
use a mixed FC4/FC5 box on another.  I can see the benefit of knowing
what packages can be rebuilt for these computers and which can not.

Enrico's posts show how the information can be problematic when mixing
distros (Fedora's php-PEAR may not use an epoch while SuSE's may.)  I
think we should remove this case from our consideration because we are
packaging for the benefit of Fedora, not users of other distros.

His posts also show how intradistro dependencies have to account for
patches and bugfixes that make a package not-quite the next version.  If
you're using virtual Provides that represent the upstream package
everywhere, how are you going to account for this?

-Toshio

[Christopher Stone]

On 7/6/06, Toshio Kuratomi <toshio(a)tiki-lounge.com&gt; wrote:
>  On Thu, 2006-07-06 at 15:11 -0700, Christopher Stone wrote:
>  > On 7/6/06, Toshio Kuratomi <toshio(a)tiki-lounge.com&gt; wrote:
>  > > On Thu, 2006-07-06 at 13:42 -0700, Christopher Stone wrote:
>  > > The message that this all stems from is here:
>  > > https://www.redhat.com/archives/fedora-packaging/2006-July/msg00050.html
>  > > the quotation by you is that you are requiring php >= 4.2.0 in some
>  > > packages; php >= 4.3.0 in others.  php 4.3.3 was already present in
>  > > Fedora Core 1 so the package version is deeply irrelevant for Fedora.
>  > ...
>  > > The rule is whether the lowest version requirement is satisfied by the
>  > > packages on Fedora's target distributions.  It may be open to
>  > > interpretation whether "target distribution release" means non-EOL
>  > > distributions (in which case FC4+ currently) or distributions the
>  > > packager is actively building for but in either case, php >= 4.2.0 being
>  > > irrelevant even for FC1 means it is too old.
>  >
>  > I have no problem with just Requiring php instead of php 4.2 because
>  > 4.2 is ancient.  Note that even my default spec file:
>  > http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec
>  > Does not have any version number listed for php.  But I do not see any
>  > harm in actually providing this information, it would seem especially
>  > important for packages that require php 5 or even php 6 when it comes
>  > out.
>  >
>  This is a different ball of wax in the beginning but becomes the same
>  later on.  Let's say FC6 is the first FC to provide php-6.0.1 and your
>  package requires php-6.0.0.  Then you can list Requires: php >= 6.0.0 in
>  your spec file.
>
>  Now, a year and a half goes by and FC6 goes EOL.  Now the supported
>  platforms are FC7, FC8, and devel.  All of these platforms have php >=
>  6.0.0.  So the version information is no longer needed.  I don't know if
>  you'll get a bug report asking to remove the versioning (probably no one
>  will notice for quite a while) but new packages should not specify the
>  Requires: php >= 6.0.0 at that point. 
I agree 100%.  The guidelines should state something like, if it
requires a php version < 18 months old, then the version should be
specified. Or something like this.

>  ...
>  His posts also show how intradistro dependencies have to account for
>  patches and bugfixes that make a package not-quite the next version.  If
>  you're using virtual Provides that represent the upstream package
>  everywhere, how are you going to account for this? 
Yes, there may be a case where you have to patch a pear package, and
some other pear package must depend on this patch being in place.  In
a case like this I would think you would use:

Requires: php-pear-Foo >= x.x-y

Instead of the usual:

Requires: php-pear(Foo) >= x.x

[Christopher Stone]

Updated pear spectemplate:
http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec

-Changed Requries(post) to use /usr/bin/pear instead of %{__pear}
since %{__pear} might have to be defined by rpm package instead of
php-pear package for this to work properly.
-Reformatted spec file to look like other spec files
  - Changed %{buildroot} to $RPM_BUILD_ROOT
  - Spacify/Adjust indentations
-Fixed an %{__rm} to just an rm

[Jason L Tibbitts III]

> >>>> "CS" == Christopher Stone
> <chris.stone(a)gmail.com&gt; writes: 
CS> I agree 100%.  The guidelines should state something like, if it
CS> requires a php version < 18 months old, then the version should be
CS> specified. Or something like this.

How about:

Use of the version is optional if it is satisfied by the originally
shipping version in all targeted Fedora releases.  (Perhaps
s/optional/discouraged/.)

Currently, that's php 5.0.4 for FC4 and 5.1.2 for FC5.  (FC3 was
4.3.9.  That should be kept in mind as the infrastructure project
might request an FC3 branch of something they'd like to use.)

 - J<

[Christopher Stone]

On 7/7/06, Jason L Tibbitts III <tibbs(a)math.uh.edu&gt; wrote:
>  >>>>> "CS" == Christopher Stone
> <chris.stone(a)gmail.com&gt; writes:
>
>  CS> I agree 100%.  The guidelines should state something like, if it
>  CS> requires a php version < 18 months old, then the version should be
>  CS> specified. Or something like this.
>
>  How about:
>
>  Use of the version is optional if it is satisfied by the originally
>  shipping version in all targeted Fedora releases.  (Perhaps
>  s/optional/discouraged/.)
>
>  Currently, that's php 5.0.4 for FC4 and 5.1.2 for FC5.  (FC3 was
>  4.3.9.  That should be kept in mind as the infrastructure project
>  might request an FC3 branch of something they'd like to use.) 
I dont see any reason why this should be discouraged, and I think it
should actaully be encouraged.  But optional is fine.

[Enrico Scholz]

chris.stone(a)gmail.com ("Christopher Stone") writes:

>  How is it not relevant?  If I use FC4 and a pear pacakge I want is
> on
>  FC5, should not installing the FC5 package do some version checking or
>  are we to assume that every fedora user is using only packages from
>  their distro release? 
I do not understand you here; on the one side, you want to use versioned
dependencies which work in a defined environment only, and now you are
speaking about packages from unknown sources?


> > Enrico has the following points:
> > 1) rpm's handling of Epochs means that versioned dependencies reference
> > package versions, not upstream versions.  Because of this, including the
> > version in the rpm when it is unnecessary for all the distributions we
> > are supporting is misleading and potentially hurts packagers on other
> > distributions.
>
>  Yes, but there are no php-pear packages that use epochs and very
>  likely that none ever will.   Yes, there is a 0.0000000001% chance
>  that some php-pear package might one day use an epoch.
>
>  The argument that version numbers potentially hurt other packagers on
>  other distributions is ludicris. 
Again: versioned dependencies like "php >= 4.2" are redundant and do not
achieve the wanted effect of requiring a program version (which is not
supported by rpm).

Existing packaging guidelines suggest already to remove such unneeded
constraints.


> > 3) The packaging guidelines already state when it is appropriate
> to
> > include versioned dependencies and this is not one of them.  This means
> > we're deciding whether to make an exception for php/pear packages rather
> > than making new policy.
>
>  No. The packaging guidelines indicate when you should NOT use version
>  numbers specifically saying not to use them if the package they refer
>  to is older than redhat 6.2 which is pretty old. 
They are very exact in this regard:

  First, if the lowest possible requirement is so old that nobody has a
  version older than that installed on any target distribution release,

The "target distribution releases" are FE4, FE5 and devel.


>  Oh and not to add the just for fun. 
Dependencies like "php >= 4.2" are just for fun.


>  Why should we include dist tags? 
Because of upgrade paths


>  Why should we include version numbers in changelogs? 
It is useful for people to see the version number in --changelog output and
compare it e.g. with the previous version listed in /var/log/yum.log. It
would make a difference when these numbers would be omitted.

But there would be absolutely no difference whether you install a package
with 'Requires: php >= 4.2' or plain 'Requires: php' on supported
targets.


>  Why should we add comments in our spec file? 
Is this really enforced? Or just an implication of the packaging rule
which requires that spec files shall be readable for the reviewer?


>  etc etc.  (I dont expect you to answer these questions, I just
> trying
>  to make a point). 
sorry; you missed this goal...


>  Hell let's just give up any hope of making a good package and
> change
>  all Guidelines to read "Just do the minimal amount that is necessary
>  to make your package work with the version of Fedora which you use". 
Again: you want to add versioned requires just because some README says
that a certain program version is required. But this can not be achieved
with rpm which allows to specify package versions only.



> > Enrico's points 1 & 2 mean that adding version
> information unnecessarily
> > can mislead foreign packagers rather than help them.  Why do you think
> > those points don't apply to PEAR packages?
>
>  Because the argument is based off a false premise.  He uses the
>  argument that since rpm has epoch capabilities, then all version
>  numbers in all spec files are totally meaningless because epochs are
>  not used by upstream packages. 
>  Therefore since the bind package uses epochs 
'bind' was used because you did not understood versioned dependencies
and I wanted to give an example of possible problems. A perhaps yet more
related example would be php-pear with its epoch of '1'.


>  we should never use version number requirements in any other
> packages
>  especially packages that will most likely never have any need for the
>  use of the epoch field. 
Epochs are an existing feature of rpm and you have to live with it. I
am heavily against establishing guidelines which enforce versioned
dependencies in the hope that future package do not use epochs.




Enrico

[Christopher Stone]

On 7/6/06, Enrico Scholz <enrico.scholz(a)informatik.tu-chemnitz.de&gt; wrote:
>  chris.stone(a)gmail.com ("Christopher Stone") writes:
>
>  > How is it not relevant?  If I use FC4 and a pear pacakge I want is on
>  > FC5, should not installing the FC5 package do some version checking or
>  > are we to assume that every fedora user is using only packages from
>  > their distro release?
>
>  I do not understand you here; on the one side, you want to use versioned
>  dependencies which work in a defined environment only, and now you are
>  speaking about packages from unknown sources?
>
>
>  >> Enrico has the following points:
>  >> 1) rpm's handling of Epochs means that versioned dependencies reference
>  >> package versions, not upstream versions.  Because of this, including the
>  >> version in the rpm when it is unnecessary for all the distributions we
>  >> are supporting is misleading and potentially hurts packagers on other
>  >> distributions.
>  >
>  > Yes, but there are no php-pear packages that use epochs and very
>  > likely that none ever will.   Yes, there is a 0.0000000001% chance
>  > that some php-pear package might one day use an epoch.
>  >
>  > The argument that version numbers potentially hurt other packagers on
>  > other distributions is ludicris.
>
>  Again: versioned dependencies like "php >= 4.2" are redundant and do not
>  achieve the wanted effect of requiring a program version (which is not
>  supported by rpm).
>
>  Existing packaging guidelines suggest already to remove such unneeded
>  constraints. 
php 4.2 is a bad example because it is so ancient.  Let's assume I am
packaging a pear package for -devel which requires php-6.0 (assume for
sake of argument that php6 comes with devel).  If i just say Requires:
php, then someone from FC-5 who wants to use my pear package does not
know that he needs php6 and can install the package without any
problems incorrectly.  If I say Requires: php >= 6.0 then someone from
FC-5 who wants to install my devel package now knows that he also has
to install php-6 from -devel as well for the package to function
properly.


>  >> 3) The packaging guidelines already state when it is appropriate to
>  >> include versioned dependencies and this is not one of them.  This means
>  >> we're deciding whether to make an exception for php/pear packages rather
>  >> than making new policy.
>  >
>  > No. The packaging guidelines indicate when you should NOT use version
>  > numbers specifically saying not to use them if the package they refer
>  > to is older than redhat 6.2 which is pretty old.
>
>  They are very exact in this regard:
>
>    First, if the lowest possible requirement is so old that nobody has a
>    version older than that installed on any target distribution release,
>
>  The "target distribution releases" are FE4, FE5 and devel. 
Then why do the guidelines use redhat6.2 as an example?  If this is
the case the guidelines should be updated.  But this still does not
take into consideration the example I outlined above.

>  > Oh and not to add the just for fun.
>
>  Dependencies like "php >= 4.2" are just for fun. 
Again bad example, see the example scenerio I outlined above.

>  > etc etc.  (I dont expect you to answer these questions, I just
> trying
>  > to make a point).
>
>  sorry; you missed this goal... 
The point I was trying to make is that although the version numbers
may not technically be required if we assume everyone is using
packages from FC5 and FC5 only, it does not take into consideration
people who want to upgrade specific packages without upgrading their
entire system.  These extra things we do in the spec file are helpful.
 Adding version numbers to changelogs is not required, but it is
helpful, comments are not required but they are helpful, etc...

>  > Hell let's just give up any hope of making a good package and change
>  > all Guidelines to read "Just do the minimal amount that is necessary
>  > to make your package work with the version of Fedora which you use".
>
>  Again: you want to add versioned requires just because some README says
>  that a certain program version is required. But this can not be achieved
>  with rpm which allows to specify package versions only. 
pear packages have a line in the spec file of the form:
Provides: php-pear(Foo) = %{version}-%{release}

This provides the upstream software version, not the package version.
This is what we use on our requires line.  So for example we do not
have:
Requires: php-pear >= ..  we have:
Requires: php-pear(PEAR) >= ...


>  >> Enrico's points 1 & 2 mean that adding version information
> unnecessarily
>  >> can mislead foreign packagers rather than help them.  Why do you think
>  >> those points don't apply to PEAR packages?
>  >
>  > Because the argument is based off a false premise.  He uses the
>  > argument that since rpm has epoch capabilities, then all version
>  > numbers in all spec files are totally meaningless because epochs are
>  > not used by upstream packages.
>
>  > Therefore since the bind package uses epochs
>
>  'bind' was used because you did not understood versioned dependencies
>  and I wanted to give an example of possible problems. A perhaps yet more
>  related example would be php-pear with its epoch of '1'. 
Again, we do not use php-pear, we use php-pear(PEAR) which provides
the upstream software version release, not the package release.


>  > we should never use version number requirements in any other packages
>  > especially packages that will most likely never have any need for the
>  > use of the epoch field.
>
>  Epochs are an existing feature of rpm and you have to live with it. I
>  am heavily against establishing guidelines which enforce versioned
>  dependencies in the hope that future package do not use epochs. 
We don't and never will use epochs, even the php-pear package which
has an epoch in the package version does not use the epoch in the
php-pear(PEAR)  version specification.

[Christopher Stone]

I have updated my pear spec template:
http://tkmame.retrogames.com/fedora-extras/spectemplate-pear.spec

Changed:
Provides:         php-pear(Foo_Bar) = %{version}-%{release}
To:
Provides:         php-pear(Foo_Bar) = %{version}

Since %{release} is not part of the upstream software version which
this Provides line is meant to provide.

[Enrico Scholz]

chris.stone(a)gmail.com ("Christopher Stone") writes:

>  pear packages have a line in the spec file of the form:
>  Provides: php-pear(Foo) = %{version}-%{release}
>
>  This provides the upstream software version, not the package version.
>  This is what we use on our requires line.  So for example we do not
>  have:
>  Requires: php-pear >= ..  we have:
>  Requires: php-pear(PEAR) >= ... 
Such virtual provides are ok but you should keep in mind, that there is
no ordering during installation; e.g. it is undefined whether

| %package -n module
| Provides: php-pear(MODULE) = 1.0

or

| %package -n module-ng
| Provides: php-pear(MODULE) = 2.0

will be installed by

| Requires: php-pear(MODULE) >= 1.0

(because of the shortest-package-name-wins rule, 'module' will be the
candidate for 'rpm')


When you enforce such declarations for php-pear packages; should not
every (non-pear) package have similar Provides:? Or, what would make
php-pear an exception here? Have php-pear modules such an unstable API
that missing version information would cause problems with a significant
amount of packages?



Enrico

[Christopher Stone]

On 7/8/06, Enrico Scholz <enrico.scholz(a)informatik.tu-chemnitz.de&gt; wrote:
>  chris.stone(a)gmail.com ("Christopher Stone") writes:
>
>  > pear packages have a line in the spec file of the form:
>  > Provides: php-pear(Foo) = %{version}-%{release}
>  >
>  > This provides the upstream software version, not the package version.
>  > This is what we use on our requires line.  So for example we do not
>  > have:
>  > Requires: php-pear >= ..  we have:
>  > Requires: php-pear(PEAR) >= ...
>
>  Such virtual provides are ok but you should keep in mind, that there is
>  no ordering during installation; e.g. it is undefined whether
>
>  | %package -n module
>  | Provides: php-pear(MODULE) = 1.0
>
>  or
>
>  | %package -n module-ng
>  | Provides: php-pear(MODULE) = 2.0
>
>  will be installed by
>
>  | Requires: php-pear(MODULE) >= 1.0
>
>  (because of the shortest-package-name-wins rule, 'module' will be the
>  candidate for 'rpm') 
This should never happen, there are some cases where you may want a
stable and an alpha version in which case you would Provide
php-pear(MODULE-alpha).

See:
http://tkmame.retrogames.com/fedora-extras/php-pear-PHPUnit2.spec
http://tkmame.retrogames.com/fedora-extras/php-pear-PHPUnit2-alpha.spec

I think something like this should be mentioned in the guidelines.

In other cases the pear module name itself changes, for example:
PHPUnit (php4) and PHPUnit2 (php5)


>  When you enforce such declarations for php-pear packages; should not
>  every (non-pear) package have similar Provides:? Or, what would make
>  php-pear an exception here? Have php-pear modules such an unstable API
>  that missing version information would cause problems with a significant
>  amount of packages? 
Yes, the pear libraries are still relatively new, and many many pear
modules are under active development.  There are quite a few which are
widely used and still not even out of alpha development stage yet.

[Ville Skyttä]

On Fri, 2006-07-07 at 00:22 +0200, Enrico Scholz wrote:

>  Again: versioned dependencies like "php >= 4.2" are
> redundant and do not
>  achieve the wanted effect of requiring a program version (which is not
>  supported by rpm). 
Sure it is.  Just add the program version you want, eg. something like
"Provides: foo(upstream) = $upstream_version" (no Epoch, most likely no
Release) to packages and start using it.  Or maybe even change rpmbuild
to do it automatically so that for every N = E:V-R package, "Provides:
N(upstream) = V" is inserted if this is something people would find
generally useful.

>  Dependencies like "php >= 4.2" are just for fun. 
Again, depends.  In this case those would be useful for folks working
with Fedora and RHEL 2.1 (which continues to be supported still for
almost 3 years and has php 4.1.2).