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. > 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. I don't own any i386 machines and it will be hard for me to test this aspect of my own packages if I do as you suggest. I like to test my packages before uploading them, unlike some people. > 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. > > dh_strip and dh_shlibdeps should both be harmless when run over the > > xfree86-ddk package, whether it ships just an archive or an unpacked > > tree (which contains only source code, headers, and Makefiles) so I see > > no reason to keep this parameter. > > Well, i was afraid it would waste time on slower arches, and > dh_shlibdeps barked on the unpacked tarball version. The unpacked > tarball does contain .so objects, so ... Ahhh. Yes, in that case dh_shlibdeps should be told to leave it alone. 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. > > 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. > 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 wisdo to share with me before i go into that ? Use --package and --rename. -- G. Branden Robinson | The software said it required Debian GNU/Linux | Windows 3.1 or better, so I branden@debian.org | installed Linux. http://people.debian.org/~branden/ |
Attachment:
signature.asc
Description: Digital signature