En/na Jesse Phillips ha escrit:
I'm going to pitch in some things I've learned from trying to set up a Debian
repository and a deb package.
Jordi Sayol i salomó Wrote:
En/na Ellery Newcomer ha escrit:
You talk
about the glibc-devel package, but this is not the only one needed by
the compiler, dmd also needs gcc (32 bits) and in Your rpm (as in mine)
do not specifies anything about arch, also there is a missing library on
Your rpm, libgcc_s.so.1 is needed too by dmd.
Really? The gcc dependency doesn't automatically bring in libgcc? Is
that what the GCCVER2 business is about?
Well, can You assure that in all rpm Linux systems (not only in Fedora/red-hat)
everything needed will be installed?
From another point of view, if You think that the libgcc_s.so.1 will be
automatically installed, Why Your rpm has these other libraries on the Requires
(dependencies) tag? libc.so.6, libm.so.6 and libstdc++.so.6
Really there is no way to assure that your package will work across allsystems
that use the same package manager. Really the distributor can take the common,
libc.so and instead use the convention c-library.shared. Luckily package naming
is pretty similar across distributions.
I'm agree.
One solution for this problem is to explain the trick needed to install
the ix86 dmd rpm package on a x86_64 system, as Walter has done withthe
same situation for the dmd deb package,
http://www.digitalmars.com/d/2.0/dmd-linux.html#installation
The trick for doing this on fedora 86_64 is just
yum install gcc glibc-devel.i686
and then putting dmd wherever. Works fine.
To make it easier, and if do not affects on a i386 installation, I'll change
"glibc-devel" for "glibc-devel(x86-32)" on the rpm dependencies.
I don't think you can have a universally accepted (i386, amd64) package. i386
systems will have their packages named without any postfix, but on amd64 distro
the packages will. If you add those packages as a requirement they aren't
available on the i386 system.
After replacing "glibc-devel" whit "glibc-devel(x86-32)" on Requires: tag, the
package properly installs on a Fedora-core-13 32 bits.
Another one is to create a x86_64 rpm package of dmd 32 bits compiler. I
don't like this solution because when dmd 64 bits appears in the near
future, this will be a source of confusion.
yeah, don't do that.
I'll not :-)
This is actually the proper way to create these packages. There won't be any
confusion; when the 64bit version becomes usable the package will then contain
a native 64bit compiler and won't have the dependencies on 32bit packages. If
you really think it is a problem name the package dmd-ia32 or whatever and then
the native 64bit compiler will replace that package.
Do You really thinks that is necessary to create a 32 bits dmd rpm/deb packages
to install them on 64 bits OS? With a few easy steps You can do the same with
the 32 bits OS packages.
And My preferred solution, create a i386 chroot machine inside Your
x86_64 system, install dmd package on it and compile Yours D programs on
it too.
I've never found a need to do this (and I also don't know how).
Try it! is clean, easy and faster than other virtual machines, for text mode. I
don't know how to install it in Fedora.
In Ubuntu just install "debootstrap". On Debian-like systems, chroot is used to
build/compile packages for other architectures than the hostsystem, if it is possible.
You still need the i386 packages installed to provide a proper root
environment. I don't see the benefit.
Sorry but this is no true. If You have a 64 bits system without 32 bits libs,
and creates a chroot dir with a 32 bits system in it, You don't need to install
any 32 bits lib on host system to run 32 bits programs inside chroot, at least
in text mode.
Another thing about the creation of dmd rpm package. As You know, dmd.conf is a
configuration file, and so, it can be changed by another futurepackages (i.e.
gtkd o qtd) or by the final user. I think is not a good solution to just put it
on the place, otherwise You have to make some checks during the package
installation, upgrading and removing process. Checkif the file exist, if not,
create it, if exist, modify it to assure thatdmd will properly compile, etc.
No, I don't have my reference to this. You do NOT have multiple packages modify the
configuration file! You can either choose a "master" packagethat provides a
program to manage the configuration file, or you put that program in a new package which
everyone would depend on. This is the practice recommended for building Debian packages.
Really? If You installs dmd and after installs a gtkd package. How do gtkd give
dmd the Include dirs, lib dirs, etc.?
Do You really thinks that dmd.conf contained on dmd package has to contain all
configurations for all the installable packages pending on dmd?
I know that this is the recommended practice for building Debian packages, but
a debian packager told me that the only way to do that is handle the dmd.conf
with preinst, prerm, postinst and postrm scripts.
Finally, I do my best to build these packages but, of course, I make alot of
mistakes, hope you tell me what can be corrected/improved. And from my side,
this is not a competition on who creates the best dmd package, I just want to
have a minimal quality dmd packages to easy install/remove on my system. If You
do the job, I'll be very happy to enjoy it.
Best regards,
--
Jordi Sayol
I hope you find this advice helpful. I am not really the authority on these
things, but it is what I have pieced together from what others do for packaging.
Many thanks.
--
Jordi Sayol
