[Fedora-packaging] PHP packaging policy notes

[Christopher Stone]

On 7/6/06, Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> wrote:
> chris.stone at gmail.com ("Christopher Stone") writes:
>
> > How is it not relevant?  If I use FC4 and a pear pacakge I want is on
> > FC5, should not installing the FC5 package do some version checking or
> > are we to assume that every fedora user is using only packages from
> > their distro release?
>
> I do not understand you here; on the one side, you want to use versioned
> dependencies which work in a defined environment only, and now you are
> speaking about packages from unknown sources?
>
>
> >> Enrico has the following points:
> >> 1) rpm's handling of Epochs means that versioned dependencies reference
> >> package versions, not upstream versions.  Because of this, including the
> >> version in the rpm when it is unnecessary for all the distributions we
> >> are supporting is misleading and potentially hurts packagers on other
> >> distributions.
> >
> > Yes, but there are no php-pear packages that use epochs and very
> > likely that none ever will.   Yes, there is a 0.0000000001% chance
> > that some php-pear package might one day use an epoch.
> >
> > The argument that version numbers potentially hurt other packagers on
> > other distributions is ludicris.
>
> Again: versioned dependencies like "php >= 4.2" are redundant and do not
> achieve the wanted effect of requiring a program version (which is not
> supported by rpm).
>
> Existing packaging guidelines suggest already to remove such unneeded
> constraints.

php 4.2 is a bad example because it is so ancient.  Let's assume I am
packaging a pear package for -devel which requires php-6.0 (assume for
sake of argument that php6 comes with devel).  If i just say Requires:
php, then someone from FC-5 who wants to use my pear package does not
know that he needs php6 and can install the package without any
problems incorrectly.  If I say Requires: php >= 6.0 then someone from
FC-5 who wants to install my devel package now knows that he also has
to install php-6 from -devel as well for the package to function
properly.


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

Then why do the guidelines use redhat6.2 as an example?  If this is
the case the guidelines should be updated.  But this still does not
take into consideration the example I outlined above.

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

Again bad example, see the example scenerio I outlined above.

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

The point I was trying to make is that although the version numbers
may not technically be required if we assume everyone is using
packages from FC5 and FC5 only, it does not take into consideration
people who want to upgrade specific packages without upgrading their
entire system.  These extra things we do in the spec file are helpful.
 Adding version numbers to changelogs is not required, but it is
helpful, comments are not required but they are helpful, etc...

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

pear packages have a line in the spec file of the form:
Provides: php-pear(Foo) = %{version}-%{release}

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


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

Again, we do not use php-pear, we use php-pear(PEAR) which provides
the upstream software version release, not the package release.


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

We don't and never will use epochs, even the php-pear package which
has an epoch in the package version does not use the epoch in the
php-pear(PEAR)  version specification.