chris.stone(a)gmail.com ("Christopher Stone") writes:
How is it not relevant? If I use FC4 and a pear pacakge I want is
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
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
> 3) The packaging guidelines already state when it is appropriate
> 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
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
to make a point).
sorry; you missed this goal...
Hell let's just give up any hope of making a good package and
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
> 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
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.