Re: debian-med newbie seeks advice on where to place packages
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
Reply to: