Max Horn wrote:
> If you need libgl, you should have a "Depends: libgl". Period.
> -rootless has this.
Not true. -rootless has Provides: libgl and Conflicts: libgl.
I think the libgl stuff (mesa package and system-libgl) were band-aids
invented to paper over deficiencies of older versions of xfree86. They
can safely be scrapped now.
> For system-xfree86, you have to install system-libgl, too.
>
> > And as a future thing, 4.2 includes freetype2 which fink could
> >take advantage of.
>
> I am not sure we should do that. What exactly would we gain? Is their
> version of freetype providing any additional features?
Tonight I feel like playing devil's advocate. (Although who is the devil
here, I am not sure, the user or newbie, maybe). Or maybe I am just too
tired :-) Anyway:
I agree with Dave. XFree86 contains freetype, period. Do you imagine
anyone installing freetype2 without Xfree?
The version numbers of freetype, BTW, are not monotonically increasing.
In XFree, libfreetype.6 is more recent than libfreetype.7, and I see in
my local freetype2 package even
/sw/lib/libfreetype.6.1.0.dylib:
/sw/lib/libfreetype.6.dylib (compatibility version 8.0.0, current
version 8.0.0)
although this is at least 3 months old.
Life for Fink users would be much easier if there were just one Xfree86
package (plus system-xfree, of course) and all these band-aids libgl,
mesa, freetype2 and also the separate -rootless package would just go
away. I think nobody would lose any functionality with this. Some
mysterious errors would probably disappear, too.
I know I am talking against the trend of the day here that goes towards
multiplying the number of packages. I am not yet convinced, for example,
of the real usefulness of the splitting off of -shlibs and -bin
packages. I'll be convinced if this allows peaceful coexistence of qt2
and qt3, and this without having to recompile qt six times for every update.
While I am playing the advocatus diaboli, let me just add that I also
don't like the osx and darwin pseudo packages. How many packages depend
on them? Last time I looked, exactly zero. If such a package really
shows up one day, why can't it just check the OS version inside its
Compile, Install, or PreInst Script, wherever it would be necessary?
There are so many real problems to solve, why solve problems that do not
yet exist?
--
Martin
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
