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.lah...@cea.fr> a écrit :
> 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.
> Up to now, manuals are put into /usr/local (it is bad to have files in
>
> /usr/local/ that belong to some rpms because sometimes /usr/local is
> an nfs
> mount (also bad but it exists), and sometimes people clear /usr/local
> assuming
> those are manualy installed files).
> more over, the manuals location is defined in multiple rpm variables:
> %manpref
> %mandir ...
> We could define all those variables in the macro file and then we
> would have
> time to:
> - fix all spec files (remove %define), check how the variables are
> used
> - move oscar man to a better place. (either /usr/share/man or
> /opt/oscar/share/man or any other safe and logical place).
>
> Another benefit of this macro file is that we could have macros with
> values that
> suit/fits the distro. (%is_mdk or distro_ver, ...)
>
> here is a sample macrofile that could be used as a good start.
> (attached)
>
> Shall I go for it?
>
> Best regards,
>
> Olivier.
>
> Le jeudi 16 juin 2011 17:43:03 geoffroy.val...@free.fr a écrit :
> > 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.lah...@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:
> > >
> > > %{expand:%%define py_ver %(python -V 2>&1| awk '{print $2}')}
> > > %{expand:%%define py_libver %(python -V 2>&1| awk '{print $2}'|cut
> -d.
> > > -f1-2)}
> > >
> > > ...
> > > %files
> > > %defattr(-,root,root)
> > > %dir /usr/%{_lib}/python%{py_libver}/site-packages/libapitest
> > > /usr/%{_lib}/python%{py_libver}/site-packages/libapitest/*
> > > ...
> > >
> > > while we could have:(provided a /etc/rpm/macros.oscar is part of
> > > oscar-devel)
> > >
> > > # no macro defs in spec
> > >
> > > ...
> > >
> > > %files
> > > %defattr(-,root,root)
> > > %dir %{python_sitelib}/libapitest
> > > %{python_sitelib}/libapitest/*
> > > ...
> > >
> > > I've attached a file that could be used as a start base.
> > > I think it could be generated from a skeleton in the oscar-base
> > > build.
> > >
> > > The big advantage of such an aproach is that it would be
> compatible
> > > with
> > > curret spec files that (re)define values, so the port to
> simplified
> > > rpm
> > > architecture would be easy and could be done spec by spec.
> > >
> > > Do you agree for such a mod?
> >
> >
> ----------------------------------------------------------------------------
> > -- EditLive Enterprise is the world's most technically advanced
> content
> > authoring tool. Experience the power of Track Changes, Inline Image
> Editing
> > and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Oscar-devel mailing list
> > Oscar-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/oscar-devel
> --
> Olivier LAHAYE
> Responsable calcul scientifique
> CEA DRT/LIST
> +33 1 69 08 13 25
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Oscar-devel mailing list
Oscar-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oscar-devel
