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
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 parent reply =?ISO-8859-1?Q?Jordi_Sayol_i_Salom=F3?= <g.sayol gmail.com> writes:
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
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
parent reply =?ISO-8859-1?Q?Jordi_Sayol_i_Salom=F3?= <g.sayol gmail.com> writes:
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.


=20
 dmd links to ctnrl.o or something like that, which is in glibc-devel an=


d=20

 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=


h.

=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
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 =?ISO-8859-1?Q?Jordi_Sayol_i_salom=F3?= <g.sayol yahoo.es> writes:
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=






r

 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=




le

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




86

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




m

 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=




lk

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




l

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




he

 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.


=20
 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
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 =?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=














)


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










l

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










ker

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








able

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








orm

 as x86_64, alpha, arm, hppa, mips, mipsel, powerpc, s390, sparc, etc=








=2E

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








y

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








ne)

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








y on

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

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








all

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








r. I

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








r

 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=








s 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 syste=




m to

 do that.

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




ave

 to do all the job.

 Best regards,


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



  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)


 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



 Jun 25 2010



 next sibling 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  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=


















cy)


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














vel

 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, mip=












sel,

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












ill

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












his

 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=












s

 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=












ler.

 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=












r

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












ams

 on it too.


 Wait, isn't there a way to say in an rpm "if the target OS is 64-bi=










t

 then insert this dependency, otherwise don't"?

 Andrei


 Until I know, there is not a direct way on rpm and deb packaging sys=








tem

 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.


=20
 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  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 reply =?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: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=




le

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




86

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




m

 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.


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


=20

 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 =




on

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


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




l

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




he

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


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




 I

 don't like this solution because when dmd 64 bits appears in the near
 future, this will be a source of confusion.


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




on

 it too.


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



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



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


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




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


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




t

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


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




s

 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.


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



--=20
Jordi Sayol



 Jun 25 2010



prev sibling  parent  =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr>  writes:


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 =




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


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


	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
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr



 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 reply =?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 =


Debian repository and a deb package.

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








y

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








ne)

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








y 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 b=




e automatically installed, Why Your rpm has these other libraries on the =
Requires (dependencies) tag? libc.so.6, libm.so.6 and libstdc++.so.6


=20
 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 tak=
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=








all

 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.

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


=2E i386 systems will have their packages named without any postfix, but =
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=








r. I

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








r

 future, this will be a source of confusion.


 yeah, don't do that.


 I'll not :-)


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


e any confusion; when the 64bit version becomes usable the package will t=
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=








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




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

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




s used to build/compile packages for other architectures    than the host=
system, if it is possible.

=20
 You still need the i386 packages installed to provide a proper root env=


ironment. I don't see the benefit.

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




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


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




lot of mistakes, hope you tell me what can be corrected/improved. And fro=
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


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


hese things, but it is what I have pieced together from what others do fo=
r packaging.

Many thanks.

--=20
Jordi Sayol



 Jun 25 2010



 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.


 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.


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.


 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.


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 reply =?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=






ge. i386 systems will have their packages named without any postfix, but =
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
 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=












ler. I

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












ear

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

 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.

=20
 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 on=
e destination architecture, like deb.


=20
 Since RPM can request a 32 bit version of a package it seems you are ab=


le to keep the same package, unless the 64 bit system needs extra package=
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=












r

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












ams 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 t=








ext 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 ho=
stsystem, if it is possible.

 You still need the i386 packages installed to provide a proper root e=






nvironment. I don't see the benefit.

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




s libs, and creates a chroot dir with a 32 bits system in it, You don't n=
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=


he specified root, so you still have the libraries "installed" on the sys=
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=








d.conf is a configuration file, and so, it can be changed by another futu=
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=






ges modify the configuration file! You can either choose a "master" 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 =




gtkd give dmd the Include dirs, lib dirs, etc.?

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




tain all configurations for all the installable packages pending on dmd?

=20
 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 wo=
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=


 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?


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




ges, 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.

=20
 You use those for modifying the package config file based on the enviro=


nment being installed to. Configuration files are supposed to only have o=
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=






 these things, but it is what I have pieced together from what others do =
for packaging.

 Many thanks.

 --=20
 Jordi Sayol


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



  parent reply 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



  parent reply =?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=






n

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




es

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





 one destination architecture, like deb.


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


=20

 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=


ce.

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






ev

 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?


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


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


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


I=20

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


l=20

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


it=20

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


=20

 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



  parent reply 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



  parent reply =?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?


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


h=20

 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



 next sibling 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  parent reply 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



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


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


e

 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



prev 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 reply =?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=




s

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


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



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


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






 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.


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


led in a=20

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


an it is=20

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


, and=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 install=


ing=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 t=


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


 command=20

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


 I've done=20

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


sary 32-

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


care of=20

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


ing 32-

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


se to run=20

 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  parent  =?ISO-8859-1?Q?Jordi_Sayol_i_salom=F3?= <g.sayol yahoo.es>  writes:


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



  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 reply "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



  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


More precisely, Synaptic is a front end to either deb or rpm, depending 
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