On Sun, May 01, 2005 at 04:43:36PM -0600, Marcelo E. Magallon wrote: > 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.
I made no requests about libosmesa6-dev, I made a request about libosmesa4-dev which is what is currently in sarge. The bug report very clearly is about libosmesa4 not 6. I see no reason libosmesa4-dev can't be fixed while 6 is stuck in sid. > > 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. Version 6 is, version 4 is not (but claims to be). > > 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. My gatherings were completely correct for sarge. For sid the situation is different. I figured since the package names are different they had major differences and that sarge was going to use the versio it had in it. If it is going to be replaced maybe it should just be removed from sarge until the new version comes in. As it is the only difference I can see from having libosmesa4-dev in sarge is that buildd's think they have a package that fullfills a build dependancy and march of trying to build packages using it only to fail building a while later when the missing header is noticed. If the package didn't exist at all or hadn't claimined to be a valid Replaces then they would have failed with a dependancy problem before even trying to build anything. Based on what I tried, if the missing header had been included in libosmesa4-dev in the first place, the builds would have worked just fine. Too late now I suppose, but I still consider libosmesa4-dev broken and in need of fixing or potentially removal (which I guess it will be if/when libosmesa6-dev gets to sarge). > 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. I imagine it has no problem using libosmesa6-dev if that was in sarge, which it isn't yet. I was just trying to find and eliminate build problems for packages in sarge. The needed fix for libosmesa4-dev seemed trivial. > > 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... Well I still think #1 ought to count as a serious policy violation, although I have no clue if it does. > > 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. So does this mean you need the header and lib to match when building? Isn't that how all libs work? Well a package with the same major lib version usually is api compatible so packages build with other versions of that major can still run without being rebuilt. Building without a header file is still difficult though. Now if a package wasn't ever supposed to use GL/osmesa.h at all, well then not including it makes sense, although then I wonder why xlibosmesa-dev included in. > 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. Well what is holding the new mesa out of sarge? Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
