OSCAR clustering developer discussions

geoffroy.vallee | 16 Jun 2011 17:43

Re: RPM build system enhancement for oscar

Olivier,

I am not against what you propose, on my side, i will not have the time to deal with this at the moment,
especially since i think this is not a priority (i would prefer to cleanup oscar-packager). If you send
patches for this and if it works both on RHEL 5 and RHEL6, i will include them. Note that we do not have a simple
way to include RPM specific files in oscar-devel from the OSCAR tree so i think a good first step will be to
first come up with a clean and well defined solution for this.

Does it make sense?

Regards,

----- "Olivier LAHAYE" <olivier.lahaye <at> cea.fr> a écrit :

> Geoffroy,
> 
> Looking a all spec files for oscar let me think that using 
> /etc/rpm/macros.oscar could greatly easy oscar rpm packaging.
> 
> I mean, we could have some macros defined here once for all instead of
> having 
> those defined from time to time in different package.
> 
> We could also use an oscar_home macro pointing to /opt.
> Thus, if one need another place, no need to edit all the spec files.
> 
> for example, python_sitedir is defined in RHEL 6 but not in previous
> releases, 
> thus, for now, we have stuffs like this:
>

(Continue reading)

headers

Olivier LAHAYE | 17 Jun 2011 15:47

Re: RPM build system enhancement for oscar

Geoffroy,

I'll work on that and post patches.
This maro files are compatible with CentOS-4.8, CentOS-5.5, Scientific Linux 
6.0, SuSE 11.1, Mandirva 2010.{0..2} and Mandriva Cooker as far as I can test. 
This means that I'm pretty sure that it's fully compatible with RHEL 4, 5 and 
6.

Aside that, and after reviewing the whole thing, I think it would be better to 
put that macro file in the empty oscar rpm or in the oscar-base rpm.
that way, macros are accessible from post/pre install scripts. (from rpm --
eval '%oscar_home' for example.

What I'm proposing is the following:

/etc/rpm/macros.oscar containing most stufs that are multiply defened within 
all the spec files (helps for concistency and easy maintenance in case of value 
change).

This file would be part of the main oscar package or oscar-base package.
It can be generated from oscar-base.spec.in or just included from this spec 
file after having been generated from the main Makefile. (when generating oscar-
base.spec from oscar-base.spec.in, you would also generate macros.oscar from 
macros.oscar.in)

Including this file now would have absolutely no impact at all on the system 
and on packages generation. Then packaging could be simplified greatly 
afterward. Port to other rpm based distro would be easier.

For example, this would help fixing the oscar man location.

(Continue reading)

headers

geoffroy.vallee | 20 Jun 2011 16:02

Re: RPM build system enhancement for oscar

Olivier,

I agree with you that it "should" work with most RPM based distros but we need to "make sure" that it works with
the distros we care about. And this is the only point i tried to make in my previous email and this will
require some work (testing).

Also:
- a macro file will NOT be included in the main OSCAR package, the main OSCAR package is not intended for this,
- the macro file MUST NOT be installed on Debian systems,
- if packages include man pages in /usr/local, let's fix it, the problem is independent from the macro file
(even if the macro file will make our life easier to fix that issue),
- the man page will NOT be installed in /opt, the decision was made to install OSCAR directly on the system,
using directories that are already in PATH and so on, like a distro does,
- if /usr/local is a NFS mount, OSCAR is not guaranteed to work (if a directory named "local" is not local,
that could be a problem),
- the macro, since only used when creating RPM should be in the oscar-devel RPM.
In other terms, as i said before, this will require some work before to happen, the infrastructure is not yet
fully ready for such a feature. Remember that i just created the oscar-devel package, it did not exist even
a few months ago. When i created the package, i had this kind of thing in mind but such capabilities should be
included the proper way otherwise i will have to spend weeks to clean it up in a few years, like i did in the
past for other parts of OSCAR.

These points must be respected otherwise i will not include any patches. Note that some other constraints
may come up later on.

Regards,

----- "Olivier LAHAYE" <olivier.lahaye <at> cea.fr> a écrit :

> Geoffroy,

(Continue reading)