[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian-med newbie seeks advice on where to place packages

Look for [KSB2] comments below.  Thanks, Michael.

Regards
-- Bhaskar

GT.M - Rock solid. Lightning fast.

On 08/12/2009 02:24 PM, Michael Banck wrote:

On Wed, Aug 12, 2009 at 10:17:53AM -0400, K.S. Bhaskar wrote:
 > On 08/12/2009 02:21 AM, Andreas Tille wrote:
 >> On Tue, Aug 11, 2009 at 06:52:24PM -0400, K.S. Bhaskar wrote:
 >
 > [KSB] <...snip...>
 >
 >> Two questions here:
 >>
 >>   1. Are you sure that there is a need to install binaries for more than
 >>      one architecture on one maschine.  While this might be possible
 >>      with multiarch support I do not think that it is really intended
 >>      here and you might consider droping the architecture from the
 >>      directory name.
 >
> [KSB] While it will not be common to have both 32- and 64-bit GT.M on > the same system, there are a few people who will want both. If I > consider that possibility now, it will make for less work later. 
Debian does not currently support this, with the exception of some
toolchain-related cross-compilation packages.  People who absolutely
need two different architectures of GT.M installed on the same box could
use /opt or /usr/local for the non-native one, maybe.
[KSB2] There is nothing that Debian needs to do explicitly to support it. If the ia32-libs package is installed, the 32-bit software just works on 64-bit systems. 



 > So, I  will sequence my work to create the 32-bit binary package
 > first, then  the source package and then the 64-bit binary package.

The general workflow should usually be to create the source package
first, then build binary packages for the desired arches from it.
[KSB2] I realize that this is the general workflow. But there are two features of GT.M that make it different from a typical package:
1. GT.M has a compiler, and there is a bootstrapping process: just as gcc binaries are required to compile gcc from source, GT.M binaries are required to build GT.M from source.
2. Although GT.M has been FOSS since 2001, the current build process is non-standard and the current distribution is tarball followed by an installation script. It will take a lot more work to Debianize the sources than the binaries.
For the above reasons, I intend to Debianize the 32-bit binaries first, then Debianize the sources and eventually Debianize the 64-bit binaries.
Reply to: