Catching up with some old messages now - sorry, but I had and still have a very busy time, writing loads of exams, and also helping with the conduction of another (and correcting exams etc.).
At 21:11 Uhr +0100 08.02.2002, Martin Costabel wrote: >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 expressed myself badly. That was exactly what I meant, it provides 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. Not necessarily true, there is a newer version of mesa available than the one in XFree86. > > 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 :-) You're welcome :) > Anyway: > >I agree with Dave. XFree86 contains freetype, period. Do you imagine >anyone installing freetype2 without Xfree? Yes. freetype2 can be used to render any ttf fonts, and not just to x-window devices. E.g. sdl-ttf uses it. >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. Note that the compatibility/current versions are set this way by freetype2 itself. Fink doesn't change them at all. The reason they are out of sync with the version in XFree86 is actually that the XFree86 guys messed it up, at least IMHO. They use their own custom build system to build it (just like e.g. for GLUT), but didn't care to check what versions the original build system uses, so they just plugged in their own. >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. First off, this would not be as simple as you descibe it, but a rather painful process. I tried to replace xfree86-base, xfree86-server and xfree86-rootless with a single package, but that involves major pain for users when they want to upgrade. I.e. a smooth upgrade is impossible. That said, I agree it would be nice to have. Sadly there is another problem: currently, -base is build with SHM support, while -rootless is built without. Reason: -base exports some symbols only when SHM support is enabled, without these, many programs would refuse to link at all. OTOH, SHM in Darwin (at least the MIT-SHM) is crippled (after all, it *is* dated, Darwin does support POSIX SHM as an alternative), so we have to disable it in -rootless or many apps start to show problems. This effect isn't easy to achieve with a single package. >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 don't see the usefulness of -bin packages yet, too, but there is no question for me regarding the -shlibs. It seems you never had to rebuild ten packages because e.g. libgal was upgraded. -shlib package solve a definitly existing problem. It's not surprising to me that debian invented a similiar system a long time ago. but since you seem to think they are bad, can you give any good alternative to them? Can you also list anything that is bad about them, except the fact that you "don't like" having them? > 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. That is lame. Getting QT 3.0 to run cleanly wasn't easy. Yeah there were a lot of revisions of that package, and it is painful to recompile it over and over. I wouldn't blame Jeffrey for this. Personally I feel that he has put a lot of good work into this, and I am grateful to him for doing this. Just don't forget, he probably recompiled qt a lot more often than you did. Of course it would be nice to have a peacefuly coexistance of both, but he's just a volunteer like we all are, and hasn't got infinite resources to spend. >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. Yes. And you know why? Because a) these two are very new, b) they don't yet work for the bindist, and c) it was never meant for many packages to depend on them. So what you say proves exactly nothing to me, but feel free to explain why you think differently :) > 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? So, what would you say if you just spent several hours to build a package, only to find out that you can't use it on your system once the install script runs? Urgh. So you will say, check in the compilescript. That's still not very nice, if the package is one of various alternatives (like with gnupg and gnupg-edg, a major example for a package that could gain from the two pseudo packages), then the user will find out he has chosen the wrong one only after the choice. Urg. And you would still have to have a check in the postinst script, since otherwise the bindist would have no protections. To me this seems very messy. OTOH the two pseudo packages solve the problem very cleanly and elegant. They correspond in fact exactly to the kernel/system packages in Debian, in case you didn't realize. The only thing I don't like about 'em is that we have to modify dpkg, but then we have to do that anyway. >There are so many real problems to solve, why solve problems that do not >yet exist? In other words you say: "Why add functionality we don't use yet." I don't think I have to comment on that :) Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:[EMAIL PROTECTED]> phone: (+49) 6151-494890 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
