On Thu, May 04, 2006 at 09:19:55AM -0600, Shaun Jackman wrote: > For the intents of a Debian maintainer, upstream essentially does not > release a source package of SWT *at all*, since it does not contain > the necessary scripts to actually build the package.
Ah, right. Essentially you're saying that with upstream's current release policy, maintaining a multiplatform package might require surprising amounts of work, and you don't want to take the risk that some future changes will make the maintainer's job a living hell. This is certainly a reasonable stance. However, I think you're overestimating the chances of this happening. Consider: the patch only contains type- and typecode-differences in _generated_ code. If you ever need to do debian-specific patches to generated code, you are screwed already, even if you only package for i386: a new upstream release might introduce changes in the generation process and then your patches wouldn't be usable any longer. So as long as you decide to package for _any_ architecture without having the true sources from upstream, adding further architectures isn't likely to add much to the risk. By the way, have you actually looked at the diff between src.zip contents in the linux-x86 and linux-x86_64 packages? The lines that differ only contain _interface_ specifications: types and names. Unless you plan on adding new functionality, you probably never need to touch these. Bug fixes would only affect actual code, and those parts are not touched by the diff. Incidentally, have you tried out if the x86_64 sources work on 32-bit x86? I don't see why they shouldn't, since the only difference is that the 64-bit sources store native pointers in longs instead of ints. It would yield a performance penalty on 32-bit, but it would allow you to support both x86 and x86_64 from the same sources. Of course, all this mess is Sun's fault. For some completely unfathomable reason, Java and JNI don't provide a primitive type for opaque native pointers, so everyone has to cast them into ints or longs... But thanks for the response. I certainly agree that Eclipse should provide their _real_ sources. Yet even if they don't, it's better to do what we can with what we have... Lauri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
