[quote]Hi, should I use the file #4431: root-system-5.16.00-p4-JinCheolKim.patch
or the file #4424: root-system-5.16.00-3.patch?
Neither. Use the patch attached to this thread.
I don’t normally do that, because it would make little sense, and I do not have access to a proper machine to run this on. That is, I need a machine that has a pristine RH install and that I have root access to (or a very helpful and patient sys-admin). The ROOT team presumably have all this, can could therefor make the spec file as part of their release procedure.
make redhat does run configure (see build/package/lib/makerpmspec.sh). The options passed to configure is what would make the biggest set of packages possible on a “normal” RH installation. In addition, the option –fail-on-missing is passed to ensure that the packages needed are there.
This will definetely solve the problem of configure stopping at rpmbuild-time (Although ROOT configure should be made to complete regardless of whether an option is valid or not, for example if a dependent library is missing-I suppose this is what your patches fix among other things).[/quote]
When preparing the spec file, a list of BuildRequires is also generated. This will ensure that the packages will only be built if all needed third-party packages are available on the build machine. This is the standard and correct way to handle build-time dependencies.
If what you’re fishing for, is to allow the build to continue even if some build-dependencies are not satisfied, it is strongly discouraged and very error prone. The ambition is to make distribution-quality packages, and “sort-cuts/conviniences” like that should be avoided at all cost.
Sure. Just write a spec file that contains the proper Provides lines. However, it’s not really a good idea to do that. If a package says it provides libFoo.so.1 it bloody well better provide libFoo.so.1. Relying on the proper installation of software outside the package system, inside the package system is error prone and breaks the package management system.
Why not simply build the ROOT RPMs in the first place? Then you’re done, and everything is working smoothly with no hacks.
and an ugly one. I’d strongly advice against that.
Well, you should always distribute “pure” sources as a tar-ball. The build system of your package should then check for the presence of ROOT, for example by using the ROOT provided Autoconf macro AC_ROOT in root.m4, or by using root-config.
The spec file needed to build your package should contain a BuildRequires: libroot-dev and then use the normal package build system. The assumption is, that if you want to build your package as an RPM, you also have gotten/build ROOT as an RPM - that is, you stay inside the package management system.
It is very unfortunate, that RPM does not allow one to make alternatives in any kind of dependencies. For example, one could imagine having
BuildRequires: libroot-dev | root-dev-proxy
and root-dev-proxy would “provide” the needed libraries. Alas, this is not possible with RPM (DPKG allows that!).
If RPM thinks there’s a package providing a service (e.g., library, server) it better well be there, and the only clean, proper, and safe way of doing that is if the package actually provides the service.
It’s unfortunate, that the worst package management system out there (RPM), is the most used. It’s also unfortunate, that FermiLab and CERN did not do a bit more research before they chose the base of their so-called “scientific” Linux distribution. RPM-based distributions are notoriously hard to customise and extend, while Debian is some much easier to deal with (witness the number of derived distributions).