Subject: apr0/apr naming scheme not getting along with pkg_chk (hard problem)
To: None <firstname.lastname@example.org>
From: Greg Troxel <email@example.com>
Date: 02/05/2007 20:09:54
I have a machine with a number of packages, including:
devel/apr - apr-0.9.12.2.0.59nb2 < apr-184.108.40.206.2.4nb1
and so 'pkg_rolling-replace -uv' does make replace package clean in
devel/apr, which happily installs apr-220.127.116.11.2.4nb1
Then, subversion-base and apache2 are both broken due to wrong
shlibs, but they are marked unsafe_depends=YES, and pkg_rr will
get to them and replace.
But, one can't install both apr0 and apr1, subversion-base by
default wants apr0, and apache2 wants only apr0, so builds of both of
The fix is to delete apr and reinstall apr0, but then this happens
Clearly something is wrong, and it's a bit hard to say what.
Candidates are (with not necessarily balanced arguments):
It seems apr0 is the "standard" version, and apr1 is the "living
on the edge" version, despite ASF's claims that 2.2.x is now
'standard' and 2.0 "legacy". So therefore renaming apr to apr0
default apr choice and apache naming:
If apr 1.x is standard, then subversion should just use it by
default. And www/apache should get 2.2, with apache20 and apache1
the old ones.
pkg_chk should realize somehow that a user running apr-0.9.x which
is current with respect to the devel/apr0 package is not really
out of date in the usual sense. Clearly somehow one decided to do
this, and branch jumps aren't really something pkg_chk should do
This should figure out all of the above and do the right thing
somehow. An argument for why it's not pkg_rr's fault is that
using pkg_chk to do updates has more or less the same issue.
On balance, I think:
1) pkg_chk should somehow not demand that apr0 be updated.
2) The naming of apr0/apr(silent 1) should be consistent with
www/apache being 2.2, and 1 and 2.0 available as apache1 and
apache20, and subversion-base should use the unsuffixed apr.
3) The Apache people should have made a way to have apr be able to
install multiple versions at the same time.
4) It would be really cool if pkg_chk knew how to find (e.g. after 2
is done) www/apache20 from an installed apache-2.0.59 built from
www/apache2 from before 2 and do the right thing with asking for
updates and pointing to www/apache20 as the place to 'make
This is hard, so I don't mean to sound too cranky. But I'm getting
used to pkg_rolling-replace just working, and thus coming to view
times when it doesn't as pointing to a bug somewhere.