>>>> "CS" == Christopher Stone
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
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
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
[ || : 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.