--=-=-=
Content-Transfer-Encoding: quoted-printable


Eric Gillespie <epg@NetBSD.org> writes:

> Greg Troxel <gdt@ir.bbn.com> writes:
>
> Sorry about this.  I'm not the biggest pkgsrc expert, but i did
> run this stuff by tech-pkg first.

I might have missed it, and really the issue is that these issues are
hard in pkgsrc, not what happened this time.

> The problem is that i tested
> *installing* but completely failed to test *upgrading*, because
> upgrading pkgsrc is a disaster, and i never do it.  I instead
> install into a new tree and update a symlink to point to it.

I can understand that, but it's actually gotten better.  I used to
build in pkg_comp chroot and do binary updates.  Now I upgrade in
place all the time with pkg_rolling-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
>> those fail.
>
> I made them require apr0 by default for compatibility.  I don't
> if that was the right decision.

It might be, but on reflection I think my issue is that if you move
the apr0 bits to the name apr0, then most packages at least should
take the new bits in the package with the same name.  Put another way,
whatever most packages need should have the normal name, and deciding
to flip apr->apr0 and apr1->apr should happen at the same time as
flipping the defaults to apr (1).

>>   apr naming:
>>=20=20
>>     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
>>     was premature.
>
> What makes you think this?  Our apr0 package represents a
> never-formally-released apr and apr-util.  apr 1.2 is *not*
> "living on the edge"; it is the supported stable version.

That's news to me - it's been in pkgsrc for years with version numbers
of 0.96 or so and they keep increasing, and they keep increasing in
lock step with apache 2 versions.  So I always figured that was normal.

>>   default apr choice and apache naming:
>>=20
>>     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.
>
> I don't object to moving the subversion packages to apr 1.2 /
> httpd 2.2 by default.  apr0 is old and dead.

If that's the case, then absolutely make everything that uses apr
default to using apr 1.2.  Presumably this includes httpd 2.0,
becauseeswitching versions of that is work for people.

Can http 2.0 use apr 1.2?  If not, then this is really an upstream
mess having tightly coupled httpd/apr is one thing, but it gets harder
if other things then depend on apr.  At least subversion can use
either.

>> 3) The Apache people should have made a way to have apr be able to
>>    install multiple versions at the same time.
>
> Yeah.  They're almost there, which had me thinking at first that
> they could be installed side-by-side.  I think the .exp file may
> be the only blocker.

I know this is hard; most packages don't do it, but the other strategy
is to be able to build all dependencies with the new version.

I think part of the bigger underlying issue is that it's hard to deal
with things like httpd 2.0 to 2.2.  It's messy because there are lots
of things that 'depend on apache2'.  pgsql and python are perhaps done
the best, but it's hard, and maybe we need an abstraction for
multiversion packages to make this easier.


--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFF/pqY+vesoDJhHiURArkAAJ9PSFNJamL3nYdRLYTT0RHBEnYszQCfQ8P/
B+XvGpzXZoRmBR8dycqfYgE=
=9StX
-----END PGP SIGNATURE-----
--=-=-=--