Root rpm

[filimon]

Dear developers,
I would like to get some information about the RPM building status of ROOT. I tried to follow the instructions in README/INSTALL but rpmbuild fails because root.spec has statically the options and --enable-pythia is no longer a configuration option. Would it be possible to produce root.spec by taking as input the file config.status that contains the developer-desired options? cheers,

filimon

[brun]

“pythia6” and not “pythia”

do ./configure --help
to see the list of all options

Rene

[filimon]

Ok, I changed by hand the option in root.spec and RPM building proceeded up to the end but the result is a root-system-xxx.rpm of 20 kilobytes… Clearly this is not the rpm for ROOT, right?

[cholm]

Hi,

The current status of the RPM building, is that you need to apply a patch to the prestine sources for it to work. I’ve attached the patch to this post. This was the outcome of a discussion on the ROOT savannah pages (see savannah.cern.ch/bugs/?28327). Note, that the bug is still open, as I haven’t had time to try an RPM build on a Red Hat/Scientific Linux machine yet.

Note, that you need to make the spec file using the redhat' target in the top-level Makefile. The reason you only get oneroot-system-5.16.00.all.rpm’ is likely because configure' failed at some point. Take a long hard look at the output frommake redhat’ to see if you can spot the error.

If, after applying the attached patch, you still cannot build the RPMs, please open a bug on savannah, and assign it to me.

Please note, that I do not have a whole lot of time at the moment, so answers may be short and I’d may ask you to make an effort yourself.

Yours,

Christian

[filimon]

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?

A general question/comment with respect to my original post. Since you have to run make redhat to produce the root.spec file with every new source release (I presume) why not enforce running configure with the packager-desired options before so root.spec can have as input for its configure line the config.status file? 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).

A more general question. Is there a way to just build an rpm that declares the ROOT libraries as “provided” (with the proper sonames) but without packaging the whole thing? My point is: Install/build ROOT normally from a tarball and then create/install a small rpm that declares the libs as provided to the rpm db so that other rpms that use ROOT libs can install without having to add --nodeps. I know it is a hack but I really want to distribute my ROOT-based software in RPM without caring if ROOT is really an RPM or not Also, any other way of cheating the rpm db to think that the ROOT libs are there would do the job.
cheers,

filimon

[cholm]

[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?
[/quote]

Neither. Use the patch attached to this thread.

A general question/comment with respect to my original post. Since you have to run make redhat to produce the root.spec file with every new source release (I presume)

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.

why not enforce running configure with the packager-desired options before so root.spec can have as input for its configure line the config.status file?

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.

[quote]
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.

A more general question. Is there a way to just build an rpm that declares the ROOT libraries as “provided” (with the proper sonames) but without packaging the whole thing?

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.

My point is: Install/build ROOT normally from a tarball and then create/install a small rpm that declares the libs as provided to the rpm db so that other rpms that use ROOT libs can install without having to add --nodeps.

Why not simply build the ROOT RPMs in the first place? Then you’re done, and everything is working smoothly with no hacks.

I know it is a hack

and an ugly one. I’d strongly advice against that.

but I really want to distribute my ROOT-based software in RPM without caring if ROOT is really an RPM or not.

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

Also, any other way of cheating the rpm db to think that the ROOT libs are there would do the job.

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

Yours,

Christian

Yours,

Christian

[cholm]

Here it is.

cvs -d :pserver:cvs@root.cern.ch:/user/cvs co root gzip -dc root-system-5.16.00-4.patch.gz | patch -p1 -droot

Yours,

Christian[/code]
root-system-5.16.00-4.patch.gz (13 KB)

[filimon]

Thanks, I will try your suggestions. I will try to build a full ROOT rpm that uses in configure every possible library that exists in the “standard” SLC4 distribution. This could be potentially usefull to others so if I make it I can put a link to my site. Otherwise I will just use the Provides solution. The distribution is for a fully controlled enviroment anyway.
cheers,

filimon