Hi Len, On Tue, Apr 26, 2005 at 01:22:46PM -0400, Len Sorensen wrote:
> This package still has no header files. Nor will it have any. Here are the contents of libosmesa6-dev_6.2.1-5_i386.deb: drwxr-xr-x root/root 0 2005-05-01 15:48:13 ./ drwxr-xr-x root/root 0 2005-05-01 15:48:07 ./usr/ drwxr-xr-x root/root 0 2005-05-01 15:48:09 ./usr/lib/ -rw-r--r-- root/root 2277258 2005-05-01 15:48:09 ./usr/lib/libOSMesa16.a -rw-r--r-- root/root 2154734 2005-05-01 15:48:09 ./usr/lib/libOSMesa32.a drwxr-xr-x root/root 0 2005-05-01 15:48:07 ./usr/share/ drwxr-xr-x root/root 0 2005-05-01 15:48:07 ./usr/share/doc/ drwxr-xr-x root/root 0 2005-05-01 15:48:10 ./usr/share/doc/libosmesa6-dev/ -rw-r--r-- root/root 20145 2004-12-09 10:06:50 ./usr/share/doc/libosmesa6-dev/changelog.gz -rw-r--r-- root/root 4847 2004-12-29 21:10:15 ./usr/share/doc/libosmesa6-dev/copyright -rw-r--r-- root/root 6984 2005-05-01 09:55:02 ./usr/share/doc/libosmesa6-dev/changelog.Debian.gz lrwxrwxrwx root/root 0 2005-05-01 15:47:51 ./usr/lib/libOSMesa16.so -> libOSMesa16.so.6 lrwxrwxrwx root/root 0 2005-05-01 15:47:53 ./usr/lib/libOSMesa32.so -> libOSMesa32.so.6 and its --info: Depends: libosmesa6 (= 6.2.1-5), mesag-dev (= 6.2.1-5) Conflicts: xlibosmesa-dev, libosmesa4-dev, libosmesa-dev Replaces: xlibosmesa-dev, libosmesa-dev Provides: xlibosmesa-dev, libosmesa-dev Please note that libosmesa6_6.2.1-5_i386.deb makes no claims regarding xlibosmesa4: Depends: mesag3 (= 6.2.1-5) If you examine mesag-dev_6.2.1-5_i386.deb, you'll find: lrwxrwxrwx root/root 0 2005-05-01 15:47:46 ./usr/lib/libOSMesa.so -> libOSMesa.so.6 and: Depends: mesag3 (= 6.2.1-5), libc6-dev, libx11-6-dev | xlibs-dev (>> 4.1.0), libxext6 | xlibs (>> 4.1.0), mesa-common-dev (= 6.2.1-5), lesstif2-dev mesa-common-dev contains: -rw-r--r-- root/root 8349 2003-06-04 18:50:26 ./usr/include/GL/osmesa.h which is the file you are looking for. If you follow thru the above, you'll see that this does indeed satisfy your request for libosmesa6-dev to provide the header files. > If it is supposed to be a valid replacement for xlibosmesa-dev as the > package clearly claims, it MUST provide GL/osmesa.h header but of > course it doesn't (nor any other headers for that matter). If you read the above, you'll notice is does and it is in fact a valid replacement for xlibosmesa-dev. > It also does not depend on any package that would provide that header > file. This causes sppc (and probably other packages too) to fail to > build on any architecture that doesn't natively support the > xlibosmesa-dev (due to missing hardware support I gather). Your gathering is actually wrong. Unless sppc is written is a very specific way (which would be, IMO, broken) it shouldn't have a problem using libosmesa6-dev. Caveat emptor: By using libosmesa6-dev your package ends up tied to mesag3, which in turn means you can't use another GL implementation! This particular side-effect is not something I'm happy with, but ATM there's no way around it, and I really rather have the X maintainers get busy with something else instead of this corner case. > This package has to do one of 3 things: > 1:Stop claiming to be a replacement for xlibosmesa-dev > 2:Start to include GL/osmesa.h > 3:Start to depend on a package that provides GL/osmesa.h I'm always happy about being told how to fix my broken packages... > Option 2 and 3 are obviously preferable since then systems without > xlibosmesa-dev can start building packages with off screen gl > support. ... particularly when the person doing the telling doesn't display much in way of clues about the inner workings of the packages. Because of the way OSmesa is written *upstream*, you need a matching libGL.so.1 library. I'm pretty sure this was not the intention that upstream had, but it's the way it is. Fixing it is not trivial. The dependencies in the 6.2.1 releases reflect this situation. If you want to help it's better to spend your energy getting said releases into testing instead of trying to fix the current release in testing. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
