On Wed, Aug 12, 2009 at 03:33:44PM -0400, K.S. Bhaskar wrote: > 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: >> >> 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.
Sure, but that is out-of-scope regarding packaging. >> > 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. That is fine - if GT.M is supposed to work with other architectures than i386 or amd64 you will have to talk to the porters though, I guess. > 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. "Debianize" usually means generating a source package. If you intend to upload binaries before the source, note that they will have to be uploaded elsewhere, e.g. the non-free courtesy repository. Michael -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
