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
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 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.
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 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.
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.
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.
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
On 6/30/06, Christopher Stone chris.stone@gmail.com 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.
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?
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
On 6/30/06, Joe Orton jorton@redhat.com 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.
On 7/2/06, Christopher Stone chris.stone@gmail.com wrote:
On 6/30/06, Joe Orton jorton@redhat.com 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 ;-)
On 7/2/06, Christopher Stone chris.stone@gmail.com 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.
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<
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.sr...
(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
On 7/3/06, Tim Jackson lists@timj.co.uk 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.sr...
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-Packaging.s...
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-Packaging-0...
Christopher Stone wrote:
On 7/3/06, Tim Jackson lists@timj.co.uk 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.sr...
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-Packaging.s...
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
On Tue, 2006-07-04 at 09:58 +0100, Tim Jackson wrote:
Christopher Stone wrote:
On 7/3/06, Tim Jackson lists@timj.co.uk 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.sr...
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-Packaging.s...
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
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
On 7/3/06, Jason L Tibbitts III tibbs@math.uh.edu 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
Christopher Stone wrote:
On 7/2/06, Christopher Stone chris.stone@gmail.com wrote:
On 6/30/06, Joe Orton jorton@redhat.com 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
"TJ" == Tim Jackson lists@timj.co.uk 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<
Jason L Tibbitts III wrote:
"TJ" == Tim Jackson lists@timj.co.uk 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
On Mon, Jul 03, 2006 at 08:54:14AM -0500, Jason L Tibbitts III wrote:
"TJ" == Tim Jackson lists@timj.co.uk 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
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@timj.co.uk 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
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
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?
"CS" == Christopher Stone chris.stone@gmail.com 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<
Le mardi 04 juillet 2006 à 13:16 -0500, Jason L Tibbitts III a écrit :
"CS" == Christopher Stone chris.stone@gmail.com 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,
tibbs@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
"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<
On 7/4/06, Jason L Tibbitts III tibbs@math.uh.edu 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.
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?
"CS" == Christopher Stone chris.stone@gmail.com 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<
On Tue, 2006-07-04 at 14:43 -0500, Jason L Tibbitts III wrote:
"CS" == Christopher Stone chris.stone@gmail.com 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.
On 7/4/06, Paul Howarth paul@city-fan.org wrote:
On Tue, 2006-07-04 at 14:43 -0500, Jason L Tibbitts III wrote:
> "CS" == Christopher Stone chris.stone@gmail.com 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.
Jason L Tibbitts III wrote:
"CS" == Christopher Stone chris.stone@gmail.com 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
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.
On 7/4/06, Christopher Stone chris.stone@gmail.com 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.
Christopher Stone wrote:
On 7/4/06, Christopher Stone chris.stone@gmail.com 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
On 7/4/06, Tim Jackson lists@timj.co.uk wrote:
Christopher Stone wrote:
On 7/4/06, Christopher Stone chris.stone@gmail.com 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.
On Tue, 2006-07-04 at 16:00 -0700, Christopher Stone wrote:
On 7/4/06, Tim Jackson lists@timj.co.uk 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
On 7/4/06, Tim Jackson lists@timj.co.uk 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.
On 7/4/06, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"CS" == Christopher Stone chris.stone@gmail.com 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.
On 7/4/06, Christopher Stone chris.stone@gmail.com 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
On 7/4/06, Christopher Stone chris.stone@gmail.com 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.
Christopher Stone wrote:
On 7/4/06, Jason L Tibbitts III tibbs@math.uh.edu wrote:
> "CS" == Christopher Stone chris.stone@gmail.com 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 ?
chris.stone@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
"ES" == Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de 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<
tibbs@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
On 7/5/06, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de wrote:
tibbs@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?
chris.stone@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
On 7/5/06, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de 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?
chris.stone@gmail.com ("Christopher Stone") writes:
On 7/5/06, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de 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
On 7/5/06, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de 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.
On Wed, 2006-07-05 at 12:10 -0700, Christopher Stone wrote:
On 7/5/06, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de 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.
On 7/5/06, Paul Howarth paul@city-fan.org wrote:
On Wed, 2006-07-05 at 12:10 -0700, Christopher Stone wrote:
On 7/5/06, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de 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
chris.stone@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
On Wed, 2006-07-05 at 11:53 -0700, Christopher Stone wrote:
On 7/5/06, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de 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.
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.
ville.skytta@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
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.
ville.skytta@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
"ES" == Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de 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<
"ES" == Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de 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<
tibbs@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
Le mercredi 05 juillet 2006 à 22:09 +0200, Enrico Scholz a écrit :
ville.skytta@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@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
On 7/5/06, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de 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.
chris.stone@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
On 7/5/06, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de wrote:
chris.stone@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?
chris.stone@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@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
On 7/6/06, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de wrote:
chris.stone@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@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.
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.
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.
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
On 7/6/06, Ralf Corsepius rc040203@freenet.de 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?
On Wed, 2006-07-05 at 23:58 -0700, Christopher Stone wrote:
On 7/5/06, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de 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
On 7/6/06, Toshio Kuratomi toshio@tiki-lounge.com wrote:
On Wed, 2006-07-05 at 23:58 -0700, Christopher Stone wrote:
On 7/5/06, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de 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:
- 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.
- 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".
- 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.
On 7/6/06, Christopher Stone chris.stone@gmail.com 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.
On Thu, 2006-07-06 at 13:42 -0700, Christopher Stone wrote:
On 7/6/06, Toshio Kuratomi toshio@tiki-lounge.com 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.
- 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
On 7/6/06, Toshio Kuratomi toshio@tiki-lounge.com 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.
On Thu, 2006-07-06 at 15:11 -0700, Christopher Stone wrote:
On 7/6/06, Toshio Kuratomi toshio@tiki-lounge.com 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:
- 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.
- Is there any harm in listing the version number requirements?
- 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
On 7/6/06, Toshio Kuratomi toshio@tiki-lounge.com wrote:
On Thu, 2006-07-06 at 15:11 -0700, Christopher Stone wrote:
On 7/6/06, Toshio Kuratomi toshio@tiki-lounge.com 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
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
"CS" == Christopher Stone chris.stone@gmail.com 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<
On 7/7/06, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"CS" == Christopher Stone chris.stone@gmail.com 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.
chris.stone@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:
- 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.
- 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
On 7/6/06, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de wrote:
chris.stone@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:
- 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.
- 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.
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.
chris.stone@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
On 7/8/06, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de wrote:
chris.stone@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.
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).
packaging@lists.fedoraproject.org