[Fedora-packaging] PHP packaging policy notes

[Toshio Kuratomi]

On Thu, 2006-07-06 at 15:11 -0700, Christopher Stone wrote:
> On 7/6/06, Toshio Kuratomi <toshio at 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:
> 1) Should I not list the version numbers for these packages just
> because these packages never existed in Fedora?
The current guidelines would say, do not list the version as no Fedora
release ships an unsatisfactory version.  If I wanted to backport the
package to FC4, the first step would be to backport the required
packages from the FE where they exists, as well, so this doesn't seem
like a huge problem.

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

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

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

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20060706/4fd7434a/attachment.bin