En/na Ellery Newcomer ha escrit:
> On 06/25/2010 10:45 AM, Jordi Sayol i salomó wrote:
>>
>> I use Ubuntu 9.10 i386, and there are a lot of 32 bit packages that do
>> not works on a 64 bit system without a previous trick (installing some
>> 32 bit library packages, etc.)
> 
> But doesn't your package manager automatically take care of those dependencies?

I have no idea about this. In my computer I only can install 386 linux version, with 32 bits packages.

> 
>>
>> Well, can You assure that in all rpm Linux systems (not only in
>> Fedora/red-hat) everything needed will be installed?
>>  From another point of view, if You think that the libgcc_s.so.1 will be
>> automatically installed, Why Your rpm has these other libraries on the
>> Requires (dependencies) tag? libc.so.6, libm.so.6 and libstdc++.so.6
> 
> Don't know. I didn't put them there. All I have is
> 
> Requires:    glibc-devel(x86-32)
> Requires:    gcc
> 
> Other stuff must have gotten added by the rpm build somehow.
> 



>>>> And My preferred solution, create a i386 chroot machine inside Your
>>>> x86_64 system, install dmd package on it and compile Yours D programs on
>>>> it too.
>>>
>>> I've never found a need to do this (and I also don't know how).
>>
>> Try it! is clean, easy and faster than other virtual machines, for text
>> mode. I don't know how to install it in Fedora.
> 
> Does it allow different versions of your OS, or just different architectures?

In Your computer (64 bits), You can install different versions of different linux OS of 32 and 64 bits.

> 
> More generally, what is it? :)

chroot command do a simple thing, changes the root "/" to a chosen directory, but prior to use it, You must install an OS on it.

> 
>> In Ubuntu just install "debootstrap". On Debian-like systems, chroot is
>> used to build/compile packages for other architectures than the host
>> system, if it is possible.
>>
>> Another thing about the creation of dmd rpm package. As You know,
>> dmd.conf is a configuration file, and so, it can be changed by another
>> future packages (i.e. gtkd o qtd) or by the final user. I think is not a
>> good solution to just put it on the place, otherwise You have to make
>> some checks during the package installation, upgrading and removing
>> process. Check if the file exist, if not, create it, if exist, modify it
>> to assure that dmd will properly compile, etc.
> 
> How much of that does the %config directive take care of?

Until I know, %config tag include the files that must keep on upgrade process, this is not so useful in this case.
If You upgrade from dmd v1.062 to v2.047, You need to add "-Ipath/to/includes/druntime/import" on dmd.conf

> 
>>
>> Finally, I do my best to build these packages but, of course, I make a
>> lot of mistakes, hope you tell me what can be corrected/improved. And
>> from my side, this is not a competition on who creates the best dmd
>> package, I just want to have a minimal quality dmd packages to easy
>> install/remove on my system. If You do the job, I'll be very happy to
>> enjoy it.
>>
>> Best regards,
> 
> 


-- 
Jordi Sayol

En/na Neal Becker ha escrit:
> Jordi Sayol i salomó wrote:
> 
>> En/na Andrei Alexandrescu ha escrit:
>>> On 06/25/2010 03:46 AM, Jordi Sayol i Salomó wrote:
>>>> En/na Ellery Newcomer ha escrit:
>>>>> On 06/24/2010 01:14 PM, Jordi Sayol i Salomó wrote:
>>>>>> En/na Ellery Newcomer ha escrit:
>>>>>>> Also note that mine doesn't fail on x86_64
>>>>>>>
>>>>>>> (you need to add glibc-devel(x86-32) specifically as a dependency)
>>>>>>>
>>>>>> Can You be more explicit?
>>>>>> I've not a 64 bit system available.
>>>>>>
>>>>> dmd links to ctnrl.o or something like that, which is in glibc-devel
>>>>> and must be 32 bit. If the 32 bit version ain't there, there be linker
>>>>> errors on compile.
>>>>>
>>>>> in the spec file, after
>>>>>
>>>>> Requires: gcc
>>>>>
>>>>> add
>>>>>
>>>>> Requires: glibc-devel(x86-32)
>>>>>
>>>>> I know nothing of specific minimum version or anything like that,
>>>>> though.
>>>>>
>>>> Many thanks for Your answer.
>>>>
>>>> This rpm package is build for a i386 platform, and it's only installable
>>>> on a i386 system (without force it to), so the dependencies are for i386
>>>> installation. Of course It can be forced to install in another platform
>>>> as x86_64, alpha, arm, hppa, mips, mipsel, powerpc, s390, sparc, etc.
>>>> but I cannot assure that the compiler will work on all of them. You talk
>>>> about the glibc-devel package, but this is not the only one needed by
>>>> the compiler, dmd also needs gcc (32 bits) and in Your rpm (as in mine)
>>>> do not specifies anything about arch, also there is a missing library on
>>>> Your rpm, libgcc_s.so.1 is needed too by dmd.
>>>>
>>>> One solution for this problem is to explain the trick needed to install
>>>> the ix86 dmd rpm package on a x86_64 system, as Walter has done with the
>>>> same situation for the dmd deb package,
>>>> http://www.digitalmars.com/d/2.0/dmd-linux.html#installation
>>>>
>>>> Another one is to create a x86_64 rpm package of dmd 32 bits compiler. I
>>>> don't like this solution because when dmd 64 bits appears in the near
>>>> future, this will be a source of confusion.
>>>>
>>>> And My preferred solution, create a i386 chroot machine inside Your
>>>> x86_64 system, install dmd package on it and compile Yours D programs on
>>>> it too.
>>> Wait, isn't there a way to say in an rpm "if the target OS is 64-bit
>>> then insert this dependency, otherwise don't"?
>>>
>>> Andrei
>>>
>> Until I know, there is not a direct way on rpm and deb packaging system to
>> do that.
>>
>> There is an scripting system to do what You want, but of course, You have
>> to do all the job.
>>
>> Best regards,
> 
> What about Requires:

Requiers: tag includes a list of packages and/or libraries needed to properly run the application, but it do not select which dependencies are needed depending if the OS is 32 or 64 bits.

-- 
Jordi Sayol

Jordi Sayol i salomó wrote:

> En/na Neal Becker ha escrit:
>> Jordi Sayol i salomó wrote:
>> 
>>> En/na Andrei Alexandrescu ha escrit:
>>>> On 06/25/2010 03:46 AM, Jordi Sayol i Salomó wrote:
>>>>> En/na Ellery Newcomer ha escrit:
>>>>>> On 06/24/2010 01:14 PM, Jordi Sayol i Salomó wrote:
>>>>>>> En/na Ellery Newcomer ha escrit:
>>>>>>>> Also note that mine doesn't fail on x86_64
>>>>>>>>
>>>>>>>> (you need to add glibc-devel(x86-32) specifically as a dependency)
>>>>>>>>
>>>>>>> Can You be more explicit?
>>>>>>> I've not a 64 bit system available.
>>>>>>>
>>>>>> dmd links to ctnrl.o or something like that, which is in glibc-devel and must be 32 bit. If the 32 bit version ain't there, there be linker errors on compile.
>>>>>>
>>>>>> in the spec file, after
>>>>>>
>>>>>> Requires: gcc
>>>>>>
>>>>>> add
>>>>>>
>>>>>> Requires: glibc-devel(x86-32)
>>>>>>
>>>>>> I know nothing of specific minimum version or anything like that, though.
>>>>>>
>>>>> Many thanks for Your answer.
>>>>>
>>>>> This rpm package is build for a i386 platform, and it's only installable on a i386 system (without force it to), so the dependencies are for i386 installation. Of course It can be forced to install in another platform as x86_64, alpha, arm, hppa, mips, mipsel, powerpc, s390, sparc, etc. but I cannot assure that the compiler will work on all of them. You talk about the glibc-devel package, but this is not the only one needed by the compiler, dmd also needs gcc (32 bits) and in Your rpm (as in mine) do not specifies anything about arch, also there is a missing library on Your rpm, libgcc_s.so.1 is needed too by dmd.
>>>>>
>>>>> One solution for this problem is to explain the trick needed to install the ix86 dmd rpm package on a x86_64 system, as Walter has done with the same situation for the dmd deb package, http://www.digitalmars.com/d/2.0/dmd-linux.html#installation
>>>>>
>>>>> Another one is to create a x86_64 rpm package of dmd 32 bits compiler. I don't like this solution because when dmd 64 bits appears in the near future, this will be a source of confusion.
>>>>>
>>>>> And My preferred solution, create a i386 chroot machine inside Your x86_64 system, install dmd package on it and compile Yours D programs on it too.
>>>> Wait, isn't there a way to say in an rpm "if the target OS is 64-bit then insert this dependency, otherwise don't"?
>>>>
>>>> Andrei
>>>>
>>> Until I know, there is not a direct way on rpm and deb packaging system to do that.
>>>
>>> There is an scripting system to do what You want, but of course, You have to do all the job.
>>>
>>> Best regards,
>> 
>> What about
>> Requires:
> 
> Requiers: tag includes a list of packages and/or libraries needed to properly run the application, but it do not select which dependencies are needed depending if the OS is 32 or 64 bits.
> 

I'm pretty sure you can put the Requires within an if clause

Here's an example I have with BuidRequires (from emacs.spec)

%ifarch %{ix86}
BuildRequires: setarch
%endif

On 06/25/2010 02:26 PM, Neal Becker wrote:
> I'm pretty sure you can put the Requires within an if clause
>
> Here's an example I have with BuidRequires (from emacs.spec)
>
> %ifarch %{ix86}
> BuildRequires: setarch
> %endif
>
>
>

does that predicate on the target OS architecture or the package's target architecture?

Ellery Newcomer wrote:
> On 06/25/2010 10:45 AM, Jordi Sayol i salomó wrote:
>>
>> Well, can You assure that in all rpm Linux systems (not only in
>> Fedora/red-hat) everything needed will be installed?
>>  From another point of view, if You think that the libgcc_s.so.1 will be
>> automatically installed, Why Your rpm has these other libraries on the
>> Requires (dependencies) tag? libc.so.6, libm.so.6 and libstdc++.so.6
> 
> Don't know. I didn't put them there. All I have is
> 
> Requires:    glibc-devel(x86-32)
> Requires:    gcc
> 
> Other stuff must have gotten added by the rpm build somehow.
> 
	Rpm automatically calls ldd on all executables and adds the
returned libraries to the list of dependencies, which only makes
sense since the binary won't run without those libraries anyway...

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

En/na Neal Becker ha escrit:
> Jordi Sayol i salomó wrote:
> 
>> En/na Neal Becker ha escrit:
>>> Jordi Sayol i salomó wrote:
>>>
>>>> En/na Andrei Alexandrescu ha escrit:
>>>>> On 06/25/2010 03:46 AM, Jordi Sayol i Salomó wrote:
>>>>>> En/na Ellery Newcomer ha escrit:
>>>>>>> On 06/24/2010 01:14 PM, Jordi Sayol i Salomó wrote:
>>>>>>>> En/na Ellery Newcomer ha escrit:
>>>>>>>>> Also note that mine doesn't fail on x86_64
>>>>>>>>>
>>>>>>>>> (you need to add glibc-devel(x86-32) specifically as a dependency)
>>>>>>>>>
>>>>>>>> Can You be more explicit?
>>>>>>>> I've not a 64 bit system available.
>>>>>>>>
>>>>>>> dmd links to ctnrl.o or something like that, which is in glibc-devel
>>>>>>> and must be 32 bit. If the 32 bit version ain't there, there be
>>>>>>> linker errors on compile.
>>>>>>>
>>>>>>> in the spec file, after
>>>>>>>
>>>>>>> Requires: gcc
>>>>>>>
>>>>>>> add
>>>>>>>
>>>>>>> Requires: glibc-devel(x86-32)
>>>>>>>
>>>>>>> I know nothing of specific minimum version or anything like that,
>>>>>>> though.
>>>>>>>
>>>>>> Many thanks for Your answer.
>>>>>>
>>>>>> This rpm package is build for a i386 platform, and it's only
>>>>>> installable on a i386 system (without force it to), so the
>>>>>> dependencies are for i386 installation. Of course It can be forced to
>>>>>> install in another platform as x86_64, alpha, arm, hppa, mips, mipsel,
>>>>>> powerpc, s390, sparc, etc. but I cannot assure that the compiler will
>>>>>> work on all of them. You talk about the glibc-devel package, but this
>>>>>> is not the only one needed by the compiler, dmd also needs gcc (32
>>>>>> bits) and in Your rpm (as in mine) do not specifies anything about
>>>>>> arch, also there is a missing library on Your rpm, libgcc_s.so.1 is
>>>>>> needed too by dmd.
>>>>>>
>>>>>> One solution for this problem is to explain the trick needed to
>>>>>> install the ix86 dmd rpm package on a x86_64 system, as Walter has
>>>>>> done with the same situation for the dmd deb package,
>>>>>> http://www.digitalmars.com/d/2.0/dmd-linux.html#installation
>>>>>>
>>>>>> Another one is to create a x86_64 rpm package of dmd 32 bits compiler.
>>>>>> I don't like this solution because when dmd 64 bits appears in the
>>>>>> near future, this will be a source of confusion.
>>>>>>
>>>>>> And My preferred solution, create a i386 chroot machine inside Your
>>>>>> x86_64 system, install dmd package on it and compile Yours D programs
>>>>>> on it too.
>>>>> Wait, isn't there a way to say in an rpm "if the target OS is 64-bit
>>>>> then insert this dependency, otherwise don't"?
>>>>>
>>>>> Andrei
>>>>>
>>>> Until I know, there is not a direct way on rpm and deb packaging system
>>>> to do that.
>>>>
>>>> There is an scripting system to do what You want, but of course, You
>>>> have to do all the job.
>>>>
>>>> Best regards,
>>> What about
>>> Requires:
>> Requiers: tag includes a list of packages and/or libraries needed to
>> properly run the application, but it do not select which dependencies are
>> needed depending if the OS is 32 or 64 bits.
>>
> 
> I'm pretty sure you can put the Requires within an if clause
> 
> Here's an example I have with BuidRequires (from emacs.spec)
> 
> %ifarch %{ix86}
> BuildRequires: setarch
> %endif

This is not for compile/build time? 


-- 
Jordi Sayol

I'm going to pitch in some things I've learned from trying to set up a Debian repository and a deb package.

Jordi Sayol i salomó Wrote:

> En/na Ellery Newcomer ha escrit:
> > 
> > You talk
> >> about the glibc-devel package, but this is not the only one needed by the compiler, dmd also needs gcc (32 bits) and in Your rpm (as in mine) do not specifies anything about arch, also there is a missing library on Your rpm, libgcc_s.so.1 is needed too by dmd.
> > 
> > Really? The gcc dependency doesn't automatically bring in libgcc? Is that what the GCCVER2 business is about?
> 
> Well, can You assure that in all rpm Linux systems (not only in Fedora/red-hat) everything needed will be installed?
> From another point of view, if You think that the libgcc_s.so.1 will be automatically installed, Why Your rpm has these other libraries on the Requires (dependencies) tag? libc.so.6, libm.so.6 and libstdc++.so.6
> 

Really there is no way to assure that your package will work across all systems that use the same package manager. Really the distributor can take the common, libc.so and instead use the convention c-library.shared. Luckily package naming is pretty similar across distributions.

> >> One solution for this problem is to explain the trick needed to install the ix86 dmd rpm package on a x86_64 system, as Walter has done with the same situation for the dmd deb package, http://www.digitalmars.com/d/2.0/dmd-linux.html#installation
> > 
> > The trick for doing this on fedora 86_64 is just
> > 
> > yum install gcc glibc-devel.i686
> > 
> > and then putting dmd wherever. Works fine.
> 
> To make it easier, and if do not affects on a i386 installation, I'll change "glibc-devel" for "glibc-devel(x86-32)" on the rpm dependencies.

I don't think you can have a universally accepted (i386, amd64) package. i386 systems will have their packages named without any postfix, but on amd64 distro the packages will. If you add those packages as a requirement they aren't available on the i386 system.


> >> Another one is to create a x86_64 rpm package of dmd 32 bits compiler. I don't like this solution because when dmd 64 bits appears in the near future, this will be a source of confusion.
> > 
> > yeah, don't do that.
> 
> I'll not :-)

This is actually the proper way to create these packages. There won't be any confusion; when the 64bit version becomes usable the package will then contain a native 64bit compiler and won't have the dependencies on 32bit packages. If you really think it is a problem name the package dmd-ia32 or whatever and then the native 64bit compiler will replace that package.


> >> And My preferred solution, create a i386 chroot machine inside Your x86_64 system, install dmd package on it and compile Yours D programs on it too.
> > 
> > I've never found a need to do this (and I also don't know how).
> 
> Try it! is clean, easy and faster than other virtual machines, for text mode. I don't know how to install it in Fedora.
> In Ubuntu just install "debootstrap". On Debian-like systems, chroot is used to build/compile packages for other architectures    than the host system, if it is possible.

You still need the i386 packages installed to provide a proper root environment. I don't see the benefit.


> Another thing about the creation of dmd rpm package. As You know, dmd.conf is a configuration file, and so, it can be changed by another future packages (i.e. gtkd o qtd) or by the final user. I think is not a good solution to just put it on the place, otherwise You have to make some checks during the package installation, upgrading and removing process. Check if the file exist, if not, create it, if exist, modify it to assure that dmd will properly compile, etc.

No, I don't have my reference to this. You do NOT have multiple packages modify the configuration file! You can either choose a "master" package that provides a program to manage the configuration file, or you put that program in a new package which everyone would depend on. This is the practice recommended for building Debian packages.


> Finally, I do my best to build these packages but, of course, I make a lot of mistakes, hope you tell me what can be corrected/improved. And from my side, this is not a competition on who creates the best dmd package, I just want to have a minimal quality dmd packages to easy install/remove on my system. If You do the job, I'll be very happy to enjoy it.
> 
> Best regards,
> -- 
> Jordi Sayol
> 

I hope you find this advice helpful. I am not really the authority on these things, but it is what I have pieced together from what others do for packaging.

En/na Jesse Phillips ha escrit:
> I'm going to pitch in some things I've learned from trying to set up a Debian repository and a deb package.
> 
> Jordi Sayol i salomó Wrote:
> 
>> En/na Ellery Newcomer ha escrit:
>>> You talk
>>>> about the glibc-devel package, but this is not the only one needed by
>>>> the compiler, dmd also needs gcc (32 bits) and in Your rpm (as in mine)
>>>> do not specifies anything about arch, also there is a missing library on
>>>> Your rpm, libgcc_s.so.1 is needed too by dmd.
>>> Really? The gcc dependency doesn't automatically bring in libgcc? Is that what the GCCVER2 business is about?
>> Well, can You assure that in all rpm Linux systems (not only in Fedora/red-hat) everything needed will be installed?
>> From another point of view, if You think that the libgcc_s.so.1 will be automatically installed, Why Your rpm has these other libraries on the Requires (dependencies) tag? libc.so.6, libm.so.6 and libstdc++.so.6
>>
> 
> Really there is no way to assure that your package will work across allsystems that use the same package manager. Really the distributor can take the common, libc.so and instead use the convention c-library.shared. Luckily package naming is pretty similar across distributions.

I'm agree.

> 
>>>> One solution for this problem is to explain the trick needed to install
>>>> the ix86 dmd rpm package on a x86_64 system, as Walter has done withthe
>>>> same situation for the dmd deb package,
>>>> http://www.digitalmars.com/d/2.0/dmd-linux.html#installation
>>> The trick for doing this on fedora 86_64 is just
>>>
>>> yum install gcc glibc-devel.i686
>>>
>>> and then putting dmd wherever. Works fine.
>> To make it easier, and if do not affects on a i386 installation, I'll change "glibc-devel" for "glibc-devel(x86-32)" on the rpm dependencies.
> 
> I don't think you can have a universally accepted (i386, amd64) package. i386 systems will have their packages named without any postfix, but on amd64 distro the packages will. If you add those packages as a requirement they aren't available on the i386 system.

After replacing "glibc-devel" whit "glibc-devel(x86-32)" on Requires: tag, the package properly installs on a Fedora-core-13 32 bits.

> 
> 
>>>> Another one is to create a x86_64 rpm package of dmd 32 bits compiler. I
>>>> don't like this solution because when dmd 64 bits appears in the near
>>>> future, this will be a source of confusion.
>>> yeah, don't do that.
>> I'll not :-)
> 
> This is actually the proper way to create these packages. There won't be any confusion; when the 64bit version becomes usable the package will then contain a native 64bit compiler and won't have the dependencies on 32bit packages. If you really think it is a problem name the package dmd-ia32 or whatever and then the native 64bit compiler will replace that package.

Do You really thinks that is necessary to create a 32 bits dmd rpm/deb packages to install them on 64 bits OS? With a few easy steps You can do the same with the 32 bits OS packages.


> 
> 
>>>> And My preferred solution, create a i386 chroot machine inside Your
>>>> x86_64 system, install dmd package on it and compile Yours D programs on
>>>> it too.
>>> I've never found a need to do this (and I also don't know how).
>> Try it! is clean, easy and faster than other virtual machines, for text mode. I don't know how to install it in Fedora.
>> In Ubuntu just install "debootstrap". On Debian-like systems, chroot is used to build/compile packages for other architectures    than the hostsystem, if it is possible.
> 
> You still need the i386 packages installed to provide a proper root environment. I don't see the benefit.

Sorry but this is no true. If You have a 64 bits system without 32 bits libs, and creates a chroot dir with a 32 bits system in it, You don't need to install any 32 bits lib on host system to run 32 bits programs inside chroot, at least in text mode.

> 
> 
>> Another thing about the creation of dmd rpm package. As You know, dmd.conf is a configuration file, and so, it can be changed by another futurepackages (i.e. gtkd o qtd) or by the final user. I think is not a good solution to just put it on the place, otherwise You have to make some checks during the package installation, upgrading and removing process. Checkif the file exist, if not, create it, if exist, modify it to assure thatdmd will properly compile, etc.
> 
> No, I don't have my reference to this. You do NOT have multiple packages modify the configuration file! You can either choose a "master" packagethat provides a program to manage the configuration file, or you put that program in a new package which everyone would depend on. This is the practice recommended for building Debian packages.

Really? If You installs dmd and after installs a gtkd package. How do gtkd give dmd the Include dirs, lib dirs, etc.?
Do You really thinks that dmd.conf contained on dmd package has to contain all configurations for all the installable packages pending on dmd?

I know that this is the recommended practice for building Debian packages, but a debian packager told me that the only way to do that is handle the dmd.conf with preinst, prerm, postinst and postrm scripts.

> 
> 
>> Finally, I do my best to build these packages but, of course, I make alot of mistakes, hope you tell me what can be corrected/improved. And from my side, this is not a competition on who creates the best dmd package, I just want to have a minimal quality dmd packages to easy install/remove on my system. If You do the job, I'll be very happy to enjoy it.
>>
>> Best regards,
>> -- 
>> Jordi Sayol
>>
> 
> I hope you find this advice helpful. I am not really the authority on these things, but it is what I have pieced together from what others do for packaging.

Many thanks.

-- 
Jordi Sayol

On Friday, June 25, 2010 13:49:41 Jordi Sayol i Salomó wrote:

> > 
> > This is actually the proper way to create these packages. There won't be any confusion; when the 64bit version becomes usable the package will then contain a native 64bit compiler and won't have the dependencies on 32bit packages. If you really think it is a problem name the package dmd-ia32 or whatever and then the native 64bit compiler will replace that package.
> 
> Do You really thinks that is necessary to create a 32 bits dmd rpm/deb packages to install them on 64 bits OS? With a few easy steps You can do the same with the 32 bits OS packages.

Personally, I think that it's _way_ nicer to have the 32-bit dmd installed in a 64-bit environment along with the few 32-bit libraries that it needs than it is to have to deal with a chroot environment. There are advantages to both, and obviously you prefer to use chroot, but personally, I hate it. I don't like dealing with a separate environment where I have to worry about installing everything I need a second time (and not just the few 32-bit libraries that dmd needs) to develop as well as constantly having to worry about whether the console that I'm currently typing at is in the chroot or not. It's far too easy to run a command that has to be run in chroot outside of it or to run a command that can't be run inside of it inside of it.

It works perfectly fine to install 32-bit dmd in a 64-bit rpm-based OS. I've done it with OpenSuSE. The only issue is making sure that you have the necessary 32- bit libraries installed (which isn't very many), and an RPM would take care of all of that for you.

If I have the choice between running 32-bit dmd in 64-bit linux or running 32- bit dmd in a 32-bit chroot inside of 64-bit linux, I'll definitely choose to run it outside of the chroot.

- Jonathan M Davis

En/na Jonathan M Davis ha escrit:
> On Friday, June 25, 2010 13:49:41 Jordi Sayol i Salomó wrote:
> 
>>> This is actually the proper way to create these packages. There won't be any confusion; when the 64bit version becomes usable the package will then contain a native 64bit compiler and won't have the dependencies on 32bit packages. If you really think it is a problem name the package dmd-ia32 or whatever and then the native 64bit compiler will replace that package.
>> Do You really thinks that is necessary to create a 32 bits dmd rpm/deb packages to install them on 64 bits OS? With a few easy steps You can do the same with the 32 bits OS packages.
> 
> Personally, I think that it's _way_ nicer to have the 32-bit dmd installed in a 64-bit environment along with the few 32-bit libraries that it needs than it is to have to deal with a chroot environment. There are advantages to both, and obviously you prefer to use chroot, but personally, I hate it. I don't like dealing with a separate environment where I have to worry about installing everything I need a second time (and not just the few 32-bit libraries that dmd needs) to develop as well as constantly having to worry about whether the console that I'm currently typing at is in the chroot or not. It's far too easy to run a command that has to be run in chroot outside of it or to run a command that can't be run inside of it inside of it.
> 
> It works perfectly fine to install 32-bit dmd in a 64-bit rpm-based OS. I've done it with OpenSuSE. The only issue is making sure that you have the necessary 32- bit libraries installed (which isn't very many), and an RPM would take care of all of that for you.
> 
> If I have the choice between running 32-bit dmd in 64-bit linux or running 32- bit dmd in a 32-bit chroot inside of 64-bit linux, I'll definitely choose to run it outside of the chroot.
> 
> - Jonathan M Davis

Basically I'm agree with You, but if You need to build a package or compile and run a program for test, with the absolute security that what's happening on Your machine is exactly the same that will happen on other systems with a different OS/version than Your host system, then chroot is helpful.

But for now I'll not build a 32bit dmd rpm/deb package exclusive for 64 bit OS

-- 
Jordi Sayol