Re: Naming a 32-bit/64-bit specific Java package
Ola Lundqvist [EMAIL PROTECTED] writes: Hi On Tue, Nov 28, 2006 at 01:41:22PM +, Matthew Johnson wrote: Is it possible to upload two different versions of the any package to the different architectures? So that you get the -64 version on 64bit archs and the -32 version on 32 bit archs? It's definitely possible to have different versions in the archive for different architectures. Not unless you make them arch specific, and then you do not really have any benefit from it anyway. If you have defined it arch: all, then that means that it will work on _all_ architectures (if you have fullfilled the dependencies). If you have something that depend on 32 vs 64 bit then it is not architecture independent. We could of course try to optimize and introduce a new category 32 bit and 64 bit, but I do not think it is that interesting to have that, especially if it is just a few (or one) package there. We already have several arch:all packages that are architecture specific for its use. You can install them everywhere (if depends even allow that) but they won't be of use there. We also have arch:all packages that have unfullfillable depends on some archs. It is relatively simple to ensure the user gets the right falvour of the package installed by using the proper depends line in the application or through a meta pacakage that pulls in just the right one. The details of having a -32 and -64 package will be hidden from the user unless seh looks closely. Regards, // Ola MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
Shaun Jackman [EMAIL PROTECTED] writes: On 11/28/06, Shaun Jackman [EMAIL PROTECTED] wrote: I'm personally leaning towards to two arch: all packages (one 32-bit, one 64-bit) and a meta-package which depends on the right one. I am considering and open to the one arch: any package though. If it affects the decision, the binary package is roughly 1.2 MB. I take it back. I implemented the arch: all method, and it wasn't that tricky, but the arch: any method is definitely technically simpler. Without a good reason, I can't see why I shouldn't use the simpler method. The argument for the arch: any case is obvious -- it's simpler -- what's the best argument for the arch: all case? Cheers, Shaun - ~6 times less mirror space/bandwith usage - saves buildd time. - simpler to allow installing 32bit and 64bit on bi-/tri-arch systems like i386, amd64, mips, mipsel, sparc, s390. Altough I only see a real demand for it on amd64 where people want a 32bit java for their browser plugin. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
Hi On Mon, Nov 27, 2006 at 10:54:11AM -0700, Shaun Jackman wrote: Although SWT uses Java, it is not entirely platform independent. It requires one jar for 32-bit architectures and one jar for 64-bit architectures. I could change libswt-gtk-3.2-java to be an What do you mean here? Do you mean that it need a different jars for different architectures or that you need to create different jars for different architectures? Architecture: any package -- it's currently an all package and does not support 32-bit architectures -- but this seems like overkill to me. I'm more inclined to release one Arch:all package for the 32-bit architectures and one Arch:all package for the 64-bit architectures. A meta-package would provide the correct dependency for a given architecture. So, my question, what to name the 32-bit package, the 64-bit package, and the meta-package? At the moment, I think I'm leaning towards... libswt-gtk-3.2-java32 libswt-gtk-3.2-java64 libswt-gtk-3.2-java Any other suggestions, or completely different approaches? As I did not fully understand the question, I can not really answer but if it is not architecture independent (all) then it should not be marked as such, which means that it should be marked as any, or the specific architectures that it really support. Regards, // Ola Thanks, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
Shaun Jackman [EMAIL PROTECTED] writes: Although SWT uses Java, it is not entirely platform independent. It requires one jar for 32-bit architectures and one jar for 64-bit architectures. I could change libswt-gtk-3.2-java to be an Architecture: any package -- it's currently an all package and does not support 32-bit architectures -- but this seems like overkill to me. I'm more inclined to release one Arch:all package for the 32-bit architectures and one Arch:all package for the 64-bit architectures. A meta-package would provide the correct dependency for a given architecture. So, my question, what to name the 32-bit package, the 64-bit package, and the meta-package? At the moment, I think I'm leaning towards... libswt-gtk-3.2-java32 libswt-gtk-3.2-java64 libswt-gtk-3.2-java Any other suggestions, or completely different approaches? Thanks, Shaun Don't forget that you have 32bit and 64bit needs on amd64. So both packages should be installable. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
Ola Lundqvist [EMAIL PROTECTED] writes: Hi On Mon, Nov 27, 2006 at 10:54:11AM -0700, Shaun Jackman wrote: Although SWT uses Java, it is not entirely platform independent. It requires one jar for 32-bit architectures and one jar for 64-bit architectures. I could change libswt-gtk-3.2-java to be an What do you mean here? Do you mean that it need a different jars for different architectures or that you need to create different jars for different architectures? Architecture: any package -- it's currently an all package and does not support 32-bit architectures -- but this seems like overkill to me. I'm more inclined to release one Arch:all package for the 32-bit architectures and one Arch:all package for the 64-bit architectures. A meta-package would provide the correct dependency for a given architecture. So, my question, what to name the 32-bit package, the 64-bit package, and the meta-package? At the moment, I think I'm leaning towards... libswt-gtk-3.2-java32 libswt-gtk-3.2-java64 libswt-gtk-3.2-java Any other suggestions, or completely different approaches? As I did not fully understand the question, I can not really answer but if it is not architecture independent (all) then it should not be marked as such, which means that it should be marked as any, or the specific architectures that it really support. Regards, // Ola The package is architecture independent except for the register/address size. So i386, m68k, ppc, mips all can use the 32bit version. S390x, amd64, ppc64, mips64 can use the 64bit version. I think having two arch:all packages is better than having 12 arch:any packages where they fall onto two sets of identical apckages. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
Hi On Tue, Nov 28, 2006 at 02:13:26PM +0100, Goswin von Brederlow wrote: ...CUT... The package is architecture independent except for the register/address size. So i386, m68k, ppc, mips all can use the 32bit version. S390x, amd64, ppc64, mips64 can use the 64bit version. I think having two arch:all packages is better than having 12 arch:any packages where they fall onto two sets of identical apckages. But you will have complicated dependency problems. Or at least users will install the wrong version, or do you intend to only release the 64 bit version on 64 bit systems? and the 32 bit version on 32 bit systems? I do not really see the point. If you can not handle this really architecture independently then you should really have it arch: any. An other alternative is to provide both jars in the same package and have a startup routine to select the correct version automatically. Regards, // Ola MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
On Tue, 28 Nov 2006, Goswin von Brederlow wrote: libswt-gtk-3.2-java32 libswt-gtk-3.2-java64 libswt-gtk-3.2-java Any other suggestions, or completely different approaches? This seems like a really bad solution. The package is architecture independent except for the register/address size. How come it depends on this and is not architecture-dependent in another way? this seems really strange. If it's all bytecode there should be no dependency, and if there are native libraries it surely needs to be arch-dependent for other things. So i386, m68k, ppc, mips all can use the 32bit version. S390x, amd64, ppc64, mips64 can use the 64bit version. I think having two arch:all packages is better than having 12 arch:any packages where they fall onto two sets of identical apckages. I'd actually go for 12 arch:any packages myself, it's an implementation detail the users don't need to see. Alternatively, is it possible to detect at runtime and load different things on different architectures? Is it possible to upload two different versions of the any package to the different architectures? So that you get the -64 version on 64bit archs and the -32 version on 32 bit archs? It's definitely possible to have different versions in the archive for different architectures. Matt -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
Matthew Johnson writes: On Tue, 28 Nov 2006, Goswin von Brederlow wrote: libswt-gtk-3.2-java32 libswt-gtk-3.2-java64 libswt-gtk-3.2-java Any other suggestions, or completely different approaches? This seems like a really bad solution. The package is architecture independent except for the register/address size. How come it depends on this and is not architecture-dependent in another way? this seems really strange. If it's all bytecode there should be no dependency, and if there are native libraries it surely needs to be arch-dependent for other things. It is all bytecode. There is a wordlength dependency because the shortest Java integer type that will fit an address is used. Andrew. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
Hi On Tue, Nov 28, 2006 at 01:41:22PM +, Matthew Johnson wrote: ...CUT... I think having two arch:all packages is better than having 12 arch:any packages where they fall onto two sets of identical apckages. I'd actually go for 12 arch:any packages myself, it's an implementation detail the users don't need to see. Agree. Alternatively, is it possible to detect at runtime and load different things on different architectures? That would be the best thing, but maybe not that easy to implement, or? Is it possible to upload two different versions of the any package to the different architectures? So that you get the -64 version on 64bit archs and the -32 version on 32 bit archs? It's definitely possible to have different versions in the archive for different architectures. Not unless you make them arch specific, and then you do not really have any benefit from it anyway. If you have defined it arch: all, then that means that it will work on _all_ architectures (if you have fullfilled the dependencies). If you have something that depend on 32 vs 64 bit then it is not architecture independent. We could of course try to optimize and introduce a new category 32 bit and 64 bit, but I do not think it is that interesting to have that, especially if it is just a few (or one) package there. Regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
On 11/28/06, Ola Lundqvist [EMAIL PROTECTED] wrote: But you will have complicated dependency problems. Or at least users will install the wrong version, or do you intend to only release the 64 bit version on 64 bit systems? and the 32 bit version on 32 bit systems? I do not really see the point. If you can not handle this really architecture independently then you should really have it arch: any. I'm personally leaning towards to two arch: all packages (one 32-bit, one 64-bit) and a meta-package which depends on the right one. I am considering and open to the one arch: any package though. If it affects the decision, the binary package is roughly 1.2 MB. Would anyone that's interested in this technical choice please throw in their opinion? The options are: 1. 2 arch-all packages, one meta-package 2. 12 arch-any packages An other alternative is to provide both jars in the same package and have a startup routine to select the correct version automatically. I veto the runtime option on the grounds that I don't like it. =) Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Naming a 32-bit/64-bit specific Java package
On 11/28/06, Shaun Jackman [EMAIL PROTECTED] wrote: I'm personally leaning towards to two arch: all packages (one 32-bit, one 64-bit) and a meta-package which depends on the right one. I am considering and open to the one arch: any package though. If it affects the decision, the binary package is roughly 1.2 MB. I take it back. I implemented the arch: all method, and it wasn't that tricky, but the arch: any method is definitely technically simpler. Without a good reason, I can't see why I shouldn't use the simpler method. The argument for the arch: any case is obvious -- it's simpler -- what's the best argument for the arch: all case? Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Naming a 32-bit/64-bit specific Java package
Although SWT uses Java, it is not entirely platform independent. It requires one jar for 32-bit architectures and one jar for 64-bit architectures. I could change libswt-gtk-3.2-java to be an Architecture: any package -- it's currently an all package and does not support 32-bit architectures -- but this seems like overkill to me. I'm more inclined to release one Arch:all package for the 32-bit architectures and one Arch:all package for the 64-bit architectures. A meta-package would provide the correct dependency for a given architecture. So, my question, what to name the 32-bit package, the 64-bit package, and the meta-package? At the moment, I think I'm leaning towards... libswt-gtk-3.2-java32 libswt-gtk-3.2-java64 libswt-gtk-3.2-java Any other suggestions, or completely different approaches? Thanks, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
