On 7/6/06, Toshio Kuratomi <toshio(a)tiki-lounge.com> wrote:
On Thu, 2006-07-06 at 15:11 -0700, Christopher Stone wrote:
> On 7/6/06, Toshio Kuratomi <toshio(a)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:
> 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
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