> > If a discussion starts about that, i will be happy to participate. :-)
> Well that was my $0.02 -- I welcome others to voice their opinions. I think this is the good time to discuss about that, especially if we want to make some plans for the after "crispy branch". On Thursday 29 November 2007, Bernard Li wrote: > Okay let me explain the situation. I believe install_cluster sets up > the environment variables ($OSCAR_HOME) correctly to begin with, > however, the issue is that let's say I install the RPM, and then > decided to run start_over, the script will bail because $OSCAR_HOME is > not set (because I didn't run install_cluster). That's why Debian policies forbids to use such environment variables (again only based on what i understand). :-) > > That's why I wanted this environment variable to be set right after > oscar-base RPM is installed (%post), since the %basedir is static > anyways and I see no harm in setting it. Another solution is to put all OSCAR related stuff in the standard locations, for instance scripts in /usr/bin, Perl modules in /usr/lib/perl5, and so on. Doing so, you do not need to setup OSCAR_HOME at all, the system founds transparently everything related to OSCAR. Of course, parts of OSCAR today do not allow that, that's why i have patches for Debian packages (similar patches or even a part of these patches can be used on RPM systems). FYI, Packman, rapt and yume are already installed that way (at least on Debian). > > But if you say this is forbidden in Debian, well, I guess we need to > look for another solution then. I think that multiple solutions are possible: 1/ RPM systems, usage of OSCAR_HOME (it seems that some people like to have this variable and install everything in /opt/oscar); Debian systems, Debian developers maintain a set of patch to install OSCAR directly into the system (note that i already did a big set of minor modifications to simplify that). 2/ we install OSCAR directly into the system and create binary packages accordingly. That requires work but i started to clean up few stuff and to create patches for that (or at least for the basic stuff). However, mid-term this approach implies that: - we rewrite the Makefile in order to have a clean 'make install' command (nice for Debian packages for which the creation procedure is based on a Makefile, and not that usefull for RPM systems since almost all our current spec files are not based on any kind of Makefile -- which BTW is not a good thing according to me), - we write man pages (at least for all the major OSCAR scripts), - a lot of small details i do not think about right now. :-) But it is clear that this advantage has the benefit to push us to implement OSCAR the large amount software are "traditionally" implemented. 3/ we continue to use OSCAR_HOME even for Debian packages (at the end this is possible) but such Debian packages cannot be accepted if one day we try to push packages directly into Debian. Personally i like the solution #2. This is doable and if we want to integrate OSCAR stuff directly into Linux distributions (nice to attract new developers/users), i think this is clearly the way to go. That's why i started to "investigate" this approach on Debian but only through patches and not "real modifications" (the patches are in trunk, in $OSCAR_HOME/debian/patches). I guess we just need to agree on the approach we should select (if possible). :-) My 2 cents, -- Geoff ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
