www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D rpm packages for Linux

reply Walter Bright <newshound2 digitalmars.com> writes:
D rpm packages now available http://www.digitalmars.com/d/download.html thanks 
to Jordi Sayol.
Jun 24 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/24/2010 12:09 PM, Walter Bright wrote:
 D rpm packages now available http://www.digitalmars.com/d/download.html
 thanks to Jordi Sayol.

Yay! I should mention that Ellery Newcomer also had an independent solution. (Sorry Ellery; I'm sure the learning experience was still useful.) Andrei
Jun 24 2010
next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 06/24/2010 12:22 PM, Andrei Alexandrescu wrote:
 On 06/24/2010 12:09 PM, Walter Bright wrote:
 D rpm packages now available http://www.digitalmars.com/d/download.html
 thanks to Jordi Sayol.

Yay! I should mention that Ellery Newcomer also had an independent solution. (Sorry Ellery; I'm sure the learning experience was still useful.) Andrei

Also note that mine doesn't fail on x86_64 (you need to add glibc-devel(x86-32) specifically as a dependency)
Jun 24 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/24/2010 12:56 PM, Ellery Newcomer wrote:
 On 06/24/2010 12:22 PM, Andrei Alexandrescu wrote:
 On 06/24/2010 12:09 PM, Walter Bright wrote:
 D rpm packages now available http://www.digitalmars.com/d/download.html
 thanks to Jordi Sayol.

Yay! I should mention that Ellery Newcomer also had an independent solution. (Sorry Ellery; I'm sure the learning experience was still useful.) Andrei

Also note that mine doesn't fail on x86_64 (you need to add glibc-devel(x86-32) specifically as a dependency)

This needs to be fixed. Walter, could you please forward this to Jordi (or better yet invite him to tune to this newsgroup)? Thanks, Andrei
Jun 24 2010
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
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.
Jun 24 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jun 25 2010
parent reply Neal Becker <ndbecker2 gmail.com> writes:
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:
Jun 25 2010
parent reply Neal Becker <ndbecker2 gmail.com> writes:
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)

I've not a 64 bit system available.

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.

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.

then insert this dependency, otherwise don't"? Andrei

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
Jun 25 2010
parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
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?
Jun 25 2010
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 06/25/2010 03:46 AM, Jordi Sayol i Salomó wrote:
 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.

Well, yeah, but from personal experience I can attest that dmd works fine on x86_64 (as does, like, every other 32 bit package), and dmd works fine with 64 bit gcc. at least on my install (fedora 13 - what do you use?). 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?
 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.
 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.
 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).
 I apologize for my bad English.

 Best regards,

Jun 25 2010
next sibling parent =?ISO-8859-1?Q?Jordi_Sayol_i_salom=F3?= <g.sayol yahoo.es> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

En/na Jordi Sayol i salom=F3 ha escrit:
 ...
 I just want to have a minimal quality dmd packages to easy=20
 install/remove on my system.
 ...

Here I mean "I just want to have dmd packages with a minimum quality leve= l..." Sorry for that :-/ Best regards, --=20 Jordi Sayol
Jun 25 2010
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
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?
 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? More generally, what is 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?
 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,

Jun 25 2010
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ellery Newcomer wrote:
 On 06/25/2010 10:45 AM, Jordi Sayol i salom=C3=B3 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 =


 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 =20 Requires: glibc-devel(x86-32) Requires: gcc =20 Other stuff must have gotten added by the rpm build somehow. =20

returned libraries to the list of dependencies, which only makes sense since the binary won't run without those libraries anyway... Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jun 25 2010
prev sibling next sibling parent =?ISO-8859-1?Q?Jordi_Sayol_i_salom=F3?= <g.sayol yahoo.es> writes:
En/na Ellery Newcomer ha escrit:
 On 06/25/2010 10:45 AM, Jordi Sayol i salom=F3 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=20 dependencies?

I have no idea about this. In my computer I only can install 386 linux ve= rsion, with 32 bits packages.
=20
 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 =


 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 =20 Requires: glibc-devel(x86-32) Requires: gcc =20 Other stuff must have gotten added by the rpm build somehow. =20

 And My preferred solution, create a i386 chroot machine inside Your
 x86_64 system, install dmd package on it and compile Yours D=20
 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 tex=


 mode. I don't know how to install it in Fedora.

Does it allow different versions of your OS, or just different=20 architectures?

In Your computer (64 bits), You can install different versions of differe= nt linux OS of 32 and 64 bits.
=20
 More generally, what is it? :)

chroot command do a simple thing, changes the root "/" to a chosen direct= ory, but prior to use it, You must install an OS on it.
=20
 In Ubuntu just install "debootstrap". On Debian-like systems, chroot i=


 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=


 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 =


 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 pro= cess, this is not so useful in this case. If You upgrade from dmd v1.062 to v2.047, You need to add "-Ipath/to/incl= udes/druntime/import" on dmd.conf
=20
 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,

=20

--=20 Jordi Sayol
Jun 25 2010
prev sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
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.
Jun 25 2010
next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Friday, June 25, 2010 13:49:41 Jordi Sayol i Salom=F3 wrote:

=20
 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=20 64-bit environment along with the few 32-bit libraries that it needs than i= t is=20 to have to deal with a chroot environment. There are advantages to both, an= d=20 obviously you prefer to use chroot, but personally, I hate it. I don't like= =20 dealing with a separate environment where I have to worry about installing= =20 everything I need a second time (and not just the few 32-bit libraries that= dmd=20 needs) to develop as well as constantly having to worry about whether the=20 console that I'm currently typing at is in the chroot or not. It's far too = easy=20 to run a command that has to be run in chroot outside of it or to run a com= mand=20 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'v= e done=20 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=20 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 t= o run=20 it outside of the chroot. =2D Jonathan M Davis
Jun 25 2010
prev sibling next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Jordi Sayol i Salomó Wrote:

 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.

Ok, that would be a difference from RPM and Deb.
 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.



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.

I'll ask you this, for RPM if it is stated to be a 32 bit package, can you installed it without "forcing" the install on a 64 bit system? Since RPM can request a 32 bit version of a package it seems you are able to keep the same package, unless the 64 bit system needs extra 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.


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.

You may not need it on the host environment but it must exsits within the specified root, so you still have the libraries "installed" on the system (for verious definitions of installed)
 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?

If you go with the "master" method then gtkd would have to require dmd. If you chose to create a separate package (dmdconf-manager) then gtkd would require that package and requests for what is needed in the .conf file would go through it (which may have its own files in /var to remember the system setup). Now what you would probably have is a libgtkd package and a libgtkd-dev package. libghtkd doesn't care about dmd.conf, but libgtkd-dev would and it wouldn't be unreasonable to depend on d-compiler. I could just be putting my foot in my mouth with all of this.
 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.

You use those for modifying the package config file based on the environment being installed to. Configuration files are supposed to only have one owner. And I agree it is the cleanest way to deal with these issues and doesn't rely on shell scripts to get it right.
 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

Yeah, this stuff seems to require quite a bit of planning.
Jun 25 2010
parent bioinfornatics <bioinfornatics gmail.com> writes:
i do'nt not use this rpm, but one thing in rpm Guideline if a package contain a
static lirbrary in package need be *-static
my 2 cents :-)
Jun 27 2010
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 06/25/2010 03:49 PM, Jordi Sayol i Salomó wrote:
 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.

maybe an alternative would be to just define /usr/lib/dmd-xxx/ /usr/include/dmd-xxx/ and in dmd.conf: [Environment] DFLAGS = -L-L/usr/lib/dmd-xxx -I/usr/include/dmd-xxx and have any additional library put its stuff directly in those two directories?
Jun 26 2010
parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 06/26/2010 09:46 AM, Jordi Sayol i Salomó wrote:
 maybe an alternative would be to just define

 /usr/lib/dmd-xxx/
 /usr/include/dmd-xxx/

 and in dmd.conf:
 [Environment]
 DFLAGS = -L-L/usr/lib/dmd-xxx -I/usr/include/dmd-xxx

 and have any additional library put its stuff directly in those two
 directories?

here are missing the linkerflags for the linker

eh?
Jun 26 2010
prev sibling parent =?ISO-8859-1?Q?Jordi_Sayol_i_Salom=F3?= <g.sayol yahoo.es> writes:
En/na Ellery Newcomer ha escrit:
 On 06/25/2010 03:49 PM, Jordi Sayol i Salom=F3 wrote:
 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 i=


 handle the dmd.conf with preinst, prerm, postinst and postrm scripts.

maybe an alternative would be to just define =20 /usr/lib/dmd-xxx/ /usr/include/dmd-xxx/ =20 and in dmd.conf: [Environment] DFLAGS =3D -L-L/usr/lib/dmd-xxx -I/usr/include/dmd-xxx =20 and have any additional library put its stuff directly in those two directories?

here are missing the linkerflags for the linker --=20 Jordi Sayol
Jun 26 2010
prev sibling next sibling parent =?ISO-8859-1?Q?Jordi_Sayol_i_salom=F3?= <g.sayol yahoo.es> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

En/na Andrei Alexandrescu ha escrit:
 On 06/25/2010 03:46 AM, Jordi Sayol i Salom=F3 wrote:
 En/na Ellery Newcomer ha escrit:
 On 06/24/2010 01:14 PM, Jordi Sayol i Salom=F3 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 linke=



 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,=20
 though.

Many thanks for Your answer. This rpm package is build for a i386 platform, and it's only installab=


 on a i386 system (without force it to), so the dependencies are for i3=


 installation. Of course It can be forced to install in another platfor=


 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 ta=


 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 =


 Your rpm, libgcc_s.so.1 is needed too by dmd.

 One solution for this problem is to explain the trick needed to instal=


 the ix86 dmd rpm package on a x86_64 system, as Walter has done with t=


 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.=


 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 =


 it too.

Wait, isn't there a way to say in an rpm "if the target OS is 64-bit=20 then insert this dependency, otherwise don't"? =20 Andrei =20

Until I know, there is not a direct way on rpm and deb packaging system t= o do that. There is an scripting system to do what You want, but of course, You have= to do all the job.=20 Best regards, --=20 Jordi Sayol
Jun 25 2010
prev sibling parent =?ISO-8859-1?Q?Jordi_Sayol_i_salom=F3?= <g.sayol yahoo.es> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

En/na Ellery Newcomer ha escrit:
 On 06/25/2010 03:46 AM, Jordi Sayol i Salom=F3 wrote:
 Many thanks for Your answer.

 This rpm package is build for a i386 platform, and it's only installab=


 on a i386 system (without force it to), so the dependencies are for i3=


 installation. Of course It can be forced to install in another platfor=


 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.

Well, yeah, but from personal experience I can attest that dmd works=20 fine on x86_64 (as does, like, every other 32 bit package), and dmd=20 works fine with 64 bit gcc. at least on my install (fedora 13 - what do=

 you use?).

I use Ubuntu 9.10 i386, and there are a lot of 32 bit packages that do no= t works on a 64 bit system without a previous trick (installing some 32 b= it library packages, etc.)
=20
 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 =


 Your rpm, libgcc_s.so.1 is needed too by dmd.

Really? The gcc dependency doesn't automatically bring in libgcc? Is=20 that what the GCCVER2 business is about?

Well, can You assure that in all rpm Linux systems (not only in Fedora/re= d-hat) everything needed will be installed? =46rom 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 R= equires (dependencies) tag? libc.so.6, libm.so.6 and libstdc++.so.6
=20
 One solution for this problem is to explain the trick needed to instal=


 the ix86 dmd rpm package on a x86_64 system, as Walter has done with t=


 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 =20 yum install gcc glibc-devel.i686 =20 and then putting dmd wherever. Works fine.

To make it easier, and if do not affects on a i386 installation, I'll cha= nge "glibc-devel" for "glibc-devel(x86-32)" on the rpm dependencies.
=20
 Another one is to create a x86_64 rpm package of dmd 32 bits compiler.=


 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 :-)
=20
 And My preferred solution, create a i386 chroot machine inside Your
 x86_64 system, install dmd package on it and compile Yours D programs =


 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 m= ode. I don't know how to install it in Fedora. In Ubuntu just install "debootstrap". On Debian-like systems, chroot is u= sed to build/compile packages for other architectures than the host sy= stem, if it is possible. Another thing about the creation of dmd rpm package. As You know, dmd.con= f is a configuration file, and so, it can be changed by another future pa= ckages (i.e. gtkd o qtd) or by the final user. I think is not a good solu= tion 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 dm= d will properly compile, etc. Finally, I do my best to build these packages but, of course, I make a lo= t 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, --=20 Jordi Sayol
Jun 25 2010
prev sibling parent =?ISO-8859-1?Q?Jordi_Sayol_i_Salom=F3?= <g.sayol gmail.com> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

En/na Ellery Newcomer ha escrit:
 On 06/24/2010 01:14 PM, Jordi Sayol i Salom=F3 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 an=

 must be 32 bit. If the 32 bit version ain't there, there  be linker=20
 errors on compile.
=20
 in the spec file, after
=20
 Requires:    gcc
=20
 add
=20
 Requires:    glibc-devel(x86-32)
=20
 I know nothing of specific minimum version or anything like that, thoug=

=20

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 a= s 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 abou= t the glibc-devel package, but this is not the only one needed by the com= piler, dmd also needs gcc (32 bits) and in Your rpm (as in mine) do not s= pecifies 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 t= he ix86 dmd rpm package on a x86_64 system, as Walter has done with the s= ame situation for the dmd deb package, http://www.digitalmars.com/d/2.0/d= md-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 fut= ure, this will be a source of confusion. And My preferred solution, create a i386 chroot machine inside Your x86_6= 4 system, install dmd package on it and compile Yours D programs on it t= oo. I apologize for my bad English. Best regards, --=20 Jordi Sayol
Jun 25 2010
prev sibling next sibling parent =?ISO-8859-1?Q?Jordi_Sayol_i_Salom=F3?= <g.sayol gmail.com> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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. -- Jordi Sayol
Jun 24 2010
prev sibling next sibling parent Graham Fawcett <fawcett uwindsor.ca> writes:
On Fri, 25 Jun 2010 17:45:00 +0200, Jordi Sayol i salomó wrote:
 En/na Ellery Newcomer ha escrit:
 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.

+1 for this. On Debian/Ubuntu systems, I find that 'schroot' makes it very easy to manage and work with chroots, including running chrooted programs from the host system. Best, Graham
Jun 25 2010
prev sibling next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
On Sat, 26 Jun 2010 15:37:40 +0200, Jordi Sayol i Salomó wrote:
 I'll ask you this, for RPM if it is stated to be a 32 bit package, can
 you installed it without "forcing" the install on a 64 bit system?

No, You have to force on 64 bits system, but You can assure dependencies in both, 32 and 64 bits systems. The binary rpm packages can only have one destination architecture, like deb.

Then I think a package should be built for each architecture. For a Debian repository a separate database is provided for each architecture so a package must be built for every architecture you wish to have the package. I guess RPM is not the same in this, so it is of less importance. I also think it is polite to give everyone a package that will just install.
 Now what you would probably have is a libgtkd package and a libgtkd-dev
 package. libghtkd doesn't care about dmd.conf, but libgtkd-dev would
 and it wouldn't be unreasonable to depend on d-compiler.

Then, I have to divide dmd into "libdmd", "libdmd-dev" and "dmd" too, isn't it?

Well, actually the proper way would be to separate it into, libphobos, libphobos-dev, dmd. And libtango is in Debian because of LDC.
 You use those for modifying the package config file based on the
 environment being installed to. Configuration files are supposed to
 only have one owner. And I agree it is the cleanest way to deal with
 these issues and doesn't rely on shell scripts to get it right.

Interesting. Can You explain a bit more how the "dmdconf-manager" package has to do the job?

I think you would probably have it take simple arguments; in English, "I am GTKD and will need these options added to dmd.conf." and then removal would just be, "I'm GTKD goodbye." Since dmd.conf should already have /usr/lib, /usr/include and stuff in it and GTKD should be installing to those directories anyway, I don't know if there is much need to manage such an installation.
Jun 26 2010
prev sibling next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
On Sat, 26 Jun 2010 17:59:01 +0200, Jordi Sayol i Salomó wrote:

 Where to place druntime lib and headers?

You could then put them in yet another lib package. I realize this is unreasonable when you don't have a repository to pull in everything needed so it is reasonable to place everything in a single package, but then you shouldn't be expecting that package to interact nicely with others.
Jun 26 2010
prev sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
On Sun, 27 Jun 2010 10:23:38 +0200, Jordi Sayol i Salomó wrote:

 With this sctructure, others packages can interact nicely with dmd now
 (one package) and in the future, because them will spect the
 "dmd.conf.manager" script on dmd package, and this do not change after
 split dmd.

My few comments. I think dmd should be packaged as dmd-2. At least for a Debian repo I couldn't find any way to store two versions for the same package. Isn't Phobos more source than headers though, I mean the only "header" it has is object.di and I don't even know why. Is it important to have a compiler specific -dev? I realize compilers don't like getting along, but what happens when phobos becomes a shared library? I thought object files were suppose to be more "universal," doesn't libc6 work when using Digital Mars C++ compilers or does it have its own? Otherwise the tree looks fine.
Jun 27 2010
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 06/24/2010 12:09 PM, Walter Bright wrote:
 D rpm packages now available http://www.digitalmars.com/d/download.html
 thanks to Jordi Sayol.

Also, what about hosting a yum repository?
Jun 24 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/24/2010 03:44 PM, Ellery Newcomer wrote:
 On 06/24/2010 12:09 PM, Walter Bright wrote:
 D rpm packages now available http://www.digitalmars.com/d/download.html
 thanks to Jordi Sayol.

Also, what about hosting a yum repository?

Is that the thing that allows me to insert a line in the Synaptic repositories and then benefit of integration goodies? I'd love something like that. Andrei
Jun 24 2010
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 06/24/2010 08:40 PM, Andrei Alexandrescu wrote:
 On 06/24/2010 03:44 PM, Ellery Newcomer wrote:
 On 06/24/2010 12:09 PM, Walter Bright wrote:
 D rpm packages now available http://www.digitalmars.com/d/download.html
 thanks to Jordi Sayol.

Also, what about hosting a yum repository?

Is that the thing that allows me to insert a line in the Synaptic repositories and then benefit of integration goodies? I'd love something like that. Andrei

Ummm.. maybe? Yum is a package manager built on top of rpm, essentially red hat's counterpart to apt-get. I think the idea is each version of dmd as an rpm lives in the yum repository, and as new versions are released, the yum will semi-automatically upgrade the user's install. The nice thing about it is the user doesn't have to go around looking for the download each time the next release of dmd comes out, although they do have to initially configure their system. Typically, the repository host provides a downloadable rpm which performs that action. I don't know that it would be particularly useful for synaptic based linuxen (Andrei, see what you've got me doing?) though. Guess we'd have to make a synaptic repo too.
Jun 24 2010
parent Charles Hixson <charleshixsn earthlink.net> writes:
On 06/24/2010 11:51 PM, Lars T. Kyllingstad wrote:
 On Thu, 24 Jun 2010 21:26:09 -0500, Ellery Newcomer wrote:

 On 06/24/2010 08:40 PM, Andrei Alexandrescu wrote:
 On 06/24/2010 03:44 PM, Ellery Newcomer wrote:
 On 06/24/2010 12:09 PM, Walter Bright wrote:
 D rpm packages now available
 http://www.digitalmars.com/d/download.html thanks to Jordi Sayol.

Also, what about hosting a yum repository?

Is that the thing that allows me to insert a line in the Synaptic repositories and then benefit of integration goodies? I'd love something like that. Andrei

Ummm.. maybe? Yum is a package manager built on top of rpm, essentially red hat's counterpart to apt-get. I think the idea is each version of dmd as an rpm lives in the yum repository, and as new versions are released, the yum will semi-automatically upgrade the user's install. The nice thing about it is the user doesn't have to go around looking for the download each time the next release of dmd comes out, although they do have to initially configure their system. Typically, the repository host provides a downloadable rpm which performs that action. I don't know that it would be particularly useful for synaptic based linuxen (Andrei, see what you've got me doing?) though. Guess we'd have to make a synaptic repo too.

Synaptic supports both deb and RPM package repositories. -Lars

on which package manager your system uses. You still need to match the file type to the package manager type. (I'm not really sure whether synaptic is a front end to rpm or to yum, as from the user's point of view it's the same. I rather suspect yum, though, as when it's using deb's it's a front end to apt-get, and apt-get handles the downloading.)
Jun 25 2010
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Thu, 24 Jun 2010 21:26:09 -0500, Ellery Newcomer wrote:

 On 06/24/2010 08:40 PM, Andrei Alexandrescu wrote:
 On 06/24/2010 03:44 PM, Ellery Newcomer wrote:
 On 06/24/2010 12:09 PM, Walter Bright wrote:
 D rpm packages now available
 http://www.digitalmars.com/d/download.html thanks to Jordi Sayol.

Also, what about hosting a yum repository?

Is that the thing that allows me to insert a line in the Synaptic repositories and then benefit of integration goodies? I'd love something like that. Andrei

Ummm.. maybe? Yum is a package manager built on top of rpm, essentially red hat's counterpart to apt-get. I think the idea is each version of dmd as an rpm lives in the yum repository, and as new versions are released, the yum will semi-automatically upgrade the user's install. The nice thing about it is the user doesn't have to go around looking for the download each time the next release of dmd comes out, although they do have to initially configure their system. Typically, the repository host provides a downloadable rpm which performs that action. I don't know that it would be particularly useful for synaptic based linuxen (Andrei, see what you've got me doing?) though. Guess we'd have to make a synaptic repo too.

Synaptic supports both deb and RPM package repositories. -Lars
Jun 24 2010
prev sibling next sibling parent =?UTF-8?B?Sm9yZGkgU2F5b2wgaSBzYWxvbcOz?= <g.sayol yahoo.es> writes:
En/na Neal Becker ha escrit:
 Jordi Sayol i salom=C3=B3 wrote:
=20
 En/na Andrei Alexandrescu ha escrit:
 On 06/25/2010 03:46 AM, Jordi Sayol i Salom=C3=B3 wrote:
 En/na Ellery Newcomer ha escrit:
 On 06/24/2010 01:14 PM, Jordi Sayol i Salom=C3=B3 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=








I've not a 64 bit system available.






 and must be 32 bit. If the 32 bit version ain't there, there be lin=





 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.

This rpm package is build for a i386 platform, and it's only install=




 on a i386 system (without force it to), so the dependencies are for =




 installation. Of course It can be forced to install in another platf=




 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 =




 about the glibc-devel package, but this is not the only one needed b=




 the compiler, dmd also needs gcc (32 bits) and in Your rpm (as in mi=




 do not specifies anything about arch, also there is a missing librar=




 Your rpm, libgcc_s.so.1 is needed too by dmd.

 One solution for this problem is to explain the trick needed to inst=




 the ix86 dmd rpm package on a x86_64 system, as Walter has done with=




 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 compile=




 don't like this solution because when dmd 64 bits appears in the nea=




 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 program=




 it too.

then insert this dependency, otherwise don't"? Andrei



 do that.

 There is an scripting system to do what You want, but of course, You h=


 to do all the job.

 Best regards,

What about=20 Requires:

Requiers: tag includes a list of packages and/or libraries needed to prop= erly run the application, but it do not select which dependencies are nee= ded depending if the OS is 32 or 64 bits. --=20 Jordi Sayol
Jun 25 2010
prev sibling next sibling parent =?UTF-8?B?Sm9yZGkgU2F5b2wgaSBTYWxvbcOz?= <g.sayol yahoo.es> writes:
En/na Neal Becker ha escrit:
 Jordi Sayol i salom=C3=B3 wrote:
=20
 En/na Neal Becker ha escrit:
 Jordi Sayol i salom=C3=B3 wrote:

 En/na Andrei Alexandrescu ha escrit:
 On 06/25/2010 03:46 AM, Jordi Sayol i Salom=C3=B3 wrote:
 En/na Ellery Newcomer ha escrit:
 On 06/24/2010 01:14 PM, Jordi Sayol i Salom=C3=B3 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 dependen=










I've not a 64 bit system available.








 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.

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=






 install in another platform as x86_64, alpha, arm, hppa, mips, mip=






 powerpc, s390, sparc, etc. but I cannot assure that the compiler w=






 work on all of them. You talk about the glibc-devel package, but t=






 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 i=






 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 compi=






 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 You=






 x86_64 system, install dmd package on it and compile Yours D progr=






 on it too.






 then insert this dependency, otherwise don't"?

 Andrei





 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,

Requires:

properly run the application, but it do not select which dependencies =


 needed depending if the OS is 32 or 64 bits.

I'm pretty sure you can put the Requires within an if clause =20 Here's an example I have with BuidRequires (from emacs.spec) =20 %ifarch %{ix86} BuildRequires: setarch %endif

This is not for compile/build time?=20 --=20 Jordi Sayol
Jun 25 2010
prev sibling next sibling parent =?ISO-8859-1?Q?Jordi_Sayol_i_Salom=F3?= <g.sayol yahoo.es> writes:
En/na Jesse Phillips ha escrit:
 I'm going to pitch in some things I've learned from trying to set up a =

=20
 Jordi Sayol i salom=F3 Wrote:
=20
 En/na Ellery Newcomer ha escrit:
 You talk
 about the glibc-devel package, but this is not the only one needed b=




 the compiler, dmd also needs gcc (32 bits) and in Your rpm (as in mi=




 do not specifies anything about arch, also there is a missing librar=




 Your rpm, libgcc_s.so.1 is needed too by dmd.




 that what the GCCVER2 business is about?



 From another point of view, if You think that the libgcc_s.so.1 will b=


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=

e the common, libc.so and instead use the convention c-library.shared. Lu= ckily package naming is pretty similar across distributions. I'm agree.
=20
 One solution for this problem is to explain the trick needed to inst=




 the ix86 dmd rpm package on a x86_64 system, as Walter has done with=




 same situation for the dmd deb package,
 http://www.digitalmars.com/d/2.0/dmd-linux.html#installation

yum install gcc glibc-devel.i686 and then putting dmd wherever. Works fine.



=20
 I don't think you can have a universally accepted (i386, amd64) package=

on amd64 distro the packages will. If you add those packages as a require= ment 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.
=20
=20
 Another one is to create a x86_64 rpm package of dmd 32 bits compile=




 don't like this solution because when dmd 64 bits appears in the nea=




 future, this will be a source of confusion.



This is actually the proper way to create these packages. There won't b=

hen contain a native 64bit compiler and won't have the dependencies on 32= bit packages. If you really think it is a problem name the package dmd-ia= 32 or whatever and then the native 64bit compiler will replace that packa= ge. Do You really thinks that is necessary to create a 32 bits dmd rpm/deb pa= ckages to install them on 64 bits OS? With a few easy steps You can do th= e same with the 32 bits OS packages.
=20
=20
 And My preferred solution, create a i386 chroot machine inside Your
 x86_64 system, install dmd package on it and compile Yours D program=




 it too.




 In Ubuntu just install "debootstrap". On Debian-like systems, chroot i=


system, if it is possible.
=20
 You still need the i386 packages installed to provide a proper root env=

Sorry but this is no true. If You have a 64 bits system without 32 bits l= ibs, 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.
=20
=20
 Another thing about the creation of dmd rpm package. As You know, dmd.=


packages (i.e. gtkd o qtd) or by the final user. I think is not a good so= lution to just put it on the place, otherwise You have to make some check= s during the package installation, upgrading and removing process. Checki= f the file exist, if not, create it, if exist, modify it to assure thatdm= d will properly compile, etc.
=20
 No, I don't have my reference to this. You do NOT have multiple 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 pra= ctice recommended for building Debian packages. Really? If You installs dmd and after installs a gtkd package. How do gtk= d give dmd the Include dirs, lib dirs, etc.? Do You really thinks that dmd.conf contained on dmd package has to contai= n 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 th= e dmd.conf with preinst, prerm, postinst and postrm scripts.
=20
=20
 Finally, I do my best to build these packages but, of course, I make a=


m 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/remov= e on my system. If You do the job, I'll be very happy to enjoy it.
 Best regards,
 --=20
 Jordi Sayol

I hope you find this advice helpful. I am not really the authority on t=

r packaging. Many thanks. --=20 Jordi Sayol
Jun 25 2010
prev sibling next sibling parent =?ISO-8859-1?Q?Jordi_Sayol_i_Salom=F3?= <g.sayol yahoo.es> writes:
En/na Jonathan M Davis ha escrit:
 On Friday, June 25, 2010 13:49:41 Jordi Sayol i Salom=F3 wrote:
=20
 This is actually the proper way to create these packages. There won't=



 any confusion; when the 64bit version becomes usable the package will=



 then contain a native 64bit compiler and won't have the dependencies =



 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.



 packages to install them on 64 bits OS? With a few easy steps You can =


 the same with the 32 bits OS packages.

Personally, I think that it's _way_ nicer to have the 32-bit dmd instal=

 64-bit environment along with the few 32-bit libraries that it needs th=

 to have to deal with a chroot environment. There are advantages to both=

 obviously you prefer to use chroot, but personally, I hate it. I don't =

 dealing with a separate environment where I have to worry about install=

 everything I need a second time (and not just the few 32-bit libraries =

 needs) to develop as well as constantly having to worry about whether t=

 console that I'm currently typing at is in the chroot or not. It's far =

 to run a command that has to be run in chroot outside of it or to run a=

 that can't be run inside of it inside of it.
=20
 It works perfectly fine to install 32-bit dmd in a 64-bit rpm-based OS.=

 it with OpenSuSE. The only issue is making sure that you have the neces=

 bit libraries installed (which isn't very many), and an RPM would take =

 all of that for you.
=20
 If I have the choice between running 32-bit dmd in 64-bit linux or runn=

 bit dmd in a 32-bit chroot inside of 64-bit linux, I'll definitely choo=

 it outside of the chroot.
=20
 - Jonathan M Davis

Basically I'm agree with You, but if You need to build a package or compi= le and run a program for test, with the absolute security that what's hap= pening on Your machine is exactly the same that will happen on other syst= ems with a different OS/version than Your host system, then chroot is hel= pful. But for now I'll not build a 32bit dmd rpm/deb package exclusive for 64 b= it OS --=20 Jordi Sayol
Jun 25 2010
prev sibling next sibling parent =?ISO-8859-1?Q?Jordi_Sayol_i_Salom=F3?= <g.sayol yahoo.es> writes:
En/na Jesse Phillips ha escrit:
 Jordi Sayol i Salom=F3 Wrote:
=20
 I don't think you can have a universally accepted (i386, amd64) packa=



on amd64 distro the packages will. If you add those packages as a require= ment they aren't available on the i386 system.
 After replacing "glibc-devel" whit "glibc-devel(x86-32)" on Requires: =


=20
 Ok, that would be a difference from RPM and Deb.

Until I know, Yes, it is.
=20
=20
 Another one is to create a x86_64 rpm package of dmd 32 bits compi=






 don't like this solution because when dmd 64 bits appears in the n=






 future, this will be a source of confusion.






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 pac= kage.
 Do You really thinks that is necessary to create a 32 bits dmd rpm/deb=


the same with the 32 bits OS packages.
=20
 I'll ask you this, for RPM if it is stated to be a 32 bit package, can =

No, You have to force on 64 bits system, but You can assure dependencies = in both, 32 and 64 bits systems. The binary rpm packages can only have on= e destination architecture, like deb.
=20
 Since RPM can request a 32 bit version of a package it seems you are ab=

s. No, adding correct dependencies, it will work on both archs, I think.=20
=20
=20
 And My preferred solution, create a i386 chroot machine inside You=






 x86_64 system, install dmd package on it and compile Yours D progr=






 it too.






 In Ubuntu just install "debootstrap". On Debian-like systems, chroot=




stsystem, if it is possible.
 You still need the i386 packages installed to provide a proper root e=



 Sorry but this is no true. If You have a 64 bits system without 32 bit=


eed to install any 32 bits lib on host system to run 32 bits programs ins= ide chroot, at least in text mode.
=20
 You may not need it on the host environment but it must exsits within t=

tem (for verious definitions of installed) Well, this is true but they are clearly separated. Every chroot dir conta= ins a full OS.
=20
=20
 Another thing about the creation of dmd rpm package. As You know, dm=




repackages (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 che= cks during the package installation, upgrading and removing process. Chec= kif 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 packa=



gethat provides a program to manage the configuration file, or you put th= at program in a new package which everyone would depend on. This is the p= ractice recommended for building Debian packages.
 Really? If You installs dmd and after installs a gtkd package. How do =


 Do You really thinks that dmd.conf contained on dmd package has to con=


=20
 If you go with the "master" method then gtkd would have to require dmd.=

uld require that package and requests for what is needed in the .conf fil= e would go through it (which may have its own files in /var to remember t= he system setup).
=20
 Now what you would probably have is a libgtkd package and a libgtkd-dev=

it wouldn't be unreasonable to depend on d-compiler. Then, I have to divide dmd into "libdmd", "libdmd-dev" and "dmd" too, isn= 't it?
=20
 I could just be putting my foot in my mouth with all of this.
=20
=20
 I know that this is the recommended practice for building Debian packa=


the dmd.conf with preinst, prerm, postinst and postrm scripts.
=20
 You use those for modifying the package config file based on the enviro=

ne owner. And I agree it is the cleanest way to deal with these issues an= d doesn't rely on shell scripts to get it right. Interesting. Can You explain a bit more how the "dmdconf-manager" package= has to do the job?
=20
 I hope you find this advice helpful. I am not really the authority on=



for packaging.
 Many thanks.

 --=20
 Jordi Sayol

Yeah, this stuff seems to require quite a bit of planning.

Well, one day I wakeup, takes breakfast, and after try to install dmd on = my ubuntu but deb package fails on install, and then decide to create my = own dmd deb package for personal use, and... ...here I am, and... :-)=20 --=20 Jordi Sayol
Jun 26 2010
prev sibling next sibling parent =?UTF-8?B?Sm9yZGkgU2F5b2wgaSBTYWxvbcOz?= <g.sayol yahoo.es> writes:
En/na Jesse Phillips ha escrit:
 On Sat, 26 Jun 2010 15:37:40 +0200, Jordi Sayol i Salom=C3=B3 wrote:
 I'll ask you this, for RPM if it is stated to be a 32 bit package, ca=



 you installed it without "forcing" the install on a 64 bit system?



 in both, 32 and 64 bits systems. The binary rpm packages can only have=


 one destination architecture, like deb.

Then I think a package should be built for each architecture. For a=20 Debian repository a separate database is provided for each architecture=

 so a package must be built for every architecture you wish to have the =

 package. I guess RPM is not the same in this, so it is of less importan=

=20
 I also think it is polite to give everyone a package that will just=20
 install.
 =20
 Now what you would probably have is a libgtkd package and a libgtkd-d=



 package. libghtkd doesn't care about dmd.conf, but libgtkd-dev would
 and it wouldn't be unreasonable to depend on d-compiler.

isn't it?

Well, actually the proper way would be to separate it into, libphobos, =

 libphobos-dev, dmd. And libtango is in Debian because of LDC.

Where to place druntime lib and headers?
=20
 You use those for modifying the package config file based on the
 environment being installed to. Configuration files are supposed to
 only have one owner. And I agree it is the cleanest way to deal with
 these issues and doesn't rely on shell scripts to get it right.

package has to do the job?

I think you would probably have it take simple arguments; in English, "=

 am GTKD and will need these options added to dmd.conf." and then remova=

 would just be, "I'm GTKD goodbye."
=20
 Since dmd.conf should already have /usr/lib, /usr/include and stuff in =

 and GTKD should be installing to those directories anyway, I don't know=

 if there is much need to manage such an installation.

GTKD needs some additional linker-flags to properly link, like "-L-lgtkd"= --=20 Jordi Sayol
Jun 26 2010
prev sibling next sibling parent =?UTF-8?B?Sm9yZGkgU2F5b2wgaSBTYWxvbcOz?= <g.sayol yahoo.es> writes:
En/na Jesse Phillips ha escrit:
 On Sat, 26 Jun 2010 17:59:01 +0200, Jordi Sayol i Salom=C3=B3 wrote:
=20
 Where to place druntime lib and headers?

You could then put them in yet another lib package. I realize this is=20 unreasonable when you don't have a repository to pull in everything=20 needed so it is reasonable to place everything in a single package,

Yes, of course =20
 but then you shouldn't be expecting that package to interact nicely wit=

 others.

Yes, it will. Look below. Resuming, the list of packages can be: "dmd" including exe files and "dmd.conf.manager" script "libphobos2-dev" including phobos headers "libphobos2-dmd-dev" including phobos static libraries compiled with dmd= "libdruntime-dev" including druntime headers "libdruntime-dmd-dev" including druntime static libraries compiled with = dmd "dmd-phobos-doc" including html pages and examples, creating some link o= n main menu "libphobos2-dmd" and "libdruntime-dmd" will appears when dmd dynamic libs= do. I'm not quite sure on "libphobos2-dev" - "libphobos2-dmd-dev" and "libdru= ntime-dev" - "libdruntime-dmd-dev" split. Another possibility is to join them into "libphobos2-dmd-dev" and "libdru= ntime-dmd-dev", or just call "libphobos2-dev" =3D> "libphobos2-headers" a= nd "libdruntime-dev" =3D> "libdruntime-headers", as ldc deb packager has = done with "tango" libraries and headers. dependencies: "dmd" depends: "libphobos2-dmd-dev" "libdruntime-dmd-dev" --others packages deeded by dmd to properly compile-- recomends: "dmd-phobos-doc" "libphobos2-dmd-dev" depends: "libphobos2-dev" "libdruntime-dmd-dev" depends: "libdruntime-dev" With this sctructure, others packages can interact nicely with dmd now (o= ne package) and in the future, because them will spect the "dmd.conf.mana= ger" script on dmd package, and this do not change after split dmd. --=20 Jordi Sayol
Jun 27 2010
prev sibling parent =?UTF-8?B?Sm9yZGkgU2F5b2wgaSBTYWxvbcOz?= <g.sayol yahoo.es> writes:
Al 27/06/10 18:11, En/na Jesse Phillips ha escrit:
 On Sun, 27 Jun 2010 10:23:38 +0200, Jordi Sayol i Salom=C3=B3 wrote:

 With this sctructure, others packages can interact nicely with dmd now=


 (one package) and in the future, because them will spect the
 "dmd.conf.manager" script on dmd package, and this do not change after=


 split dmd.

My few comments. I think dmd should be packaged as dmd-2. At least for a Debian repo I couldn't find any way to store two versions for the same package.

well, if we follow this rule, just one dmd v1.xxx release and dmd v2.xxx = release can be installed at same time. Otherwise dmd v.2.xxx is still dmd= , don't dmd2 program. So, if You think that is interesting to have more t= han one dmd release at same time, then the solution is to create packages= with the name dmd-{version}, and install them in a unique {version} dir.= With this, You will be able to install every dmd release. But the problem here is for packages depending on dmd, like gtkd. A solut= ion can be have available both, "dmd" and "dmd-{version} packages.
 Isn't Phobos more source than headers though, I mean the only "header" =

 has is object.di and I don't even know why.

 Is it important to have a compiler specific -dev? I realize compilers
 don't like getting along, but what happens when phobos becomes a shared=

 library? I thought object files were suppose to be more "universal,"
 doesn't libc6 work when using Digital Mars C++ compilers or does it hav=

 its own?

Until I know, libc6 only links with gcc. dmd linux uses ld (from gcc) to = link and probably Digital Mars C++ do too. The static libraires are only useful at compile time and there are 3 d co= mpilers, so statics libs are just for one compiler and for dev, this is t= he reason.
 Otherwise the tree looks fine.

I want to continue discussing about dmd packaging, but i don't know if th= is list is the appropriate place to do it. Is there a better place? Many thanks, --=20 Jordi Sayol
Jun 28 2010