D rpm packages for Linux

[Jesse Phillips]

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.