D rpm packages for Linux

Jesse Phillips jessekphillips+D at gmail.com
Fri Jun 25 12:52:37 PDT 2010


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.



More information about the Digitalmars-d-announce mailing list