On Mon, Nov 03, 2003 at 08:59:30PM -0500, Branden Robinson wrote: > On Mon, Nov 03, 2003 at 09:35:53AM +0100, Sven Luther wrote: > > On Sun, Nov 02, 2003 at 06:01:22PM -0500, Branden Robinson wrote: > > > Why should the DDK be restricted to only some architectures? > > > > Because the SDK is 170Mo big, and the resulting tarball is 50Mo big, and > > since it is bzip2ed, it will take hours to be generated on m68k. > > Maybe bzip2 is not the wisest choice of a compression method, then.
Your call. It is a compromise between compressed tarball size and compression time. > > Don't know if it is a reason to disable it, but i thought having a > > easy way to disable it temporary would be a good thing, but again, i > > am not enough familiar with these issues, your call. > > I can think of one good reason not to switch it off for non-i386 > architectures. Did i say on non-i386 ? I did only speak about some arches. Also, i am pretty sure that m68k at least will hardly benefit from recompiled drivers or other new drivers. I may be wrong though. > I like to test my packages before uploading them, unlike some people. I do to. The fact of uploading as sources or not has hardly anything to do with it. In fact, i was again bitten by my 4.3.0 install, i built lablgl on my system, and now it pulled some OpenGL symbols only present in the 4.3.0 mesa libs. I think the mesa libs should benefit from having an API virtual depend or something such. > > But then, maybe not, i have not looked into this really but from my > > knowledge of what happens in the make install.sdk, it should be the same > > on all arches. > > Yeah, if it basically just slices off a big hunk of the source tree > irrespective of what drivers are getting *built*, then that should be > arch-independent. > > I'm not sure what S/390 will do, though. > ... > > Wait, wait, wait. You're saying "make install.sdk should be the same on > all arches" and yet the unpacked tarball contains shared objects? > > If the tarball ships a compiled object, when did that object get > compiled? > > I smell conflicting premises. Well, i was speaking of file list and not of file content. It even ships a copy of the X server anyway. > Ahhh. Yes, in that case dh_shlibdeps should be told to leave it alone. Well, it is a tarball now, so i guess it is not needed anymore. > > > > I'll have to get MANIFEST updates from all the arches and that will slow > > > this down even more than the wait in NEW, I suspect. > > > > Ok. But maybe it won't be necessary. > > /me frowns > > It will if anything's getting compiled, I'll wager. Ok, you have more experience on this. > > Well, the driver packages are only supposed to divert the corresponding > > drivers, so it should be pretty straightforward. But then, if you have > > any dpkg-divert wisdom to share with me before i go into that ? > > Use --package and --rename. Ok, i will keep that in mind. I will use this to build my unreleased wildcat VP driver and see what happens (currently using a selfbuilt X server :)). Friendly, Sven Luther
