> In message <p0511170fb9c130cfa786@[128.113.24.47]>, Garance A Drosihn
writes:
>
> >I think it would be very prudent that any base-system expat have
> >it's own name, even if it's just "expat2fb". I have no opinion
> >on whether that should be the full expat2 or a stripped down
> >functionality, but I think we should make it clear that "this
> >is the expat which the base system needs -- if you do not like
> >this version, then use the appropriate port and don't complain
> >to us about which version we install in the base system".
>
> It sounds to me like this sums it up nicely. The thing about it
> I like is that it does not prevent us from taking the other route
> later on, whereas putting an "official-looking" expat in the tree
> and yanking that later would be a mess.
>
> Any famous last words before the fat lady sings ?
Well, playing the devil's advocate -- isn't this the type of discussion the
preceeded the introduction of Perl into the base system, the introduction of
which created such a mess that we finally took Perl out of the base system
in -CURRENT?
Now I realize that expat is much less complicated than Perl, but have we
fully addressed interoperability concerns? I know that the /usr vs
${LOCALDIR}distinction between the base system and ports fixes most of them,
at least for experienced users.
My biggest concern is the minority of users installing expat2 from
ports/packages and then not being able to figure out how to use it, since
they always get expat1 since /usr/bin comes before /usr/local/bin in $PATH.
I'm sure there will also be issues with autoconf-based ports that don't do
proper version checking of libraries which will pick up static libs /
headers from /usr instead of /usr/local as well.
--
Matt Emmerton
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
