I agree with Dave.
On Apr 27, 2005, at 4:14 PM, Lombard, David N wrote:
From: Geoffroy Vall�e on Wednesday, April 27, 2005 1:17 PM
In the current install_script, we have the following code: # Sanity check: ensure that /tftpboot/rpm exists
oscar_log_subsection("Quick sanity check for /tftpboot/rpm"); if (! -d "/tftpboot/rpm") { print("ERROR: /tftpboot/rpm directory does not exist. blabla.\n"); die("Cannot continue"); } [...]
This can be done better; you're later solution is fine.
# Check to see if rpms for tftp and/or tftp-server are installed. # If so, remove them because they conflict with the tftp-hpa rpm. foreach my $rpm ('tftp', 'tftp-server') { if ( !system("rpm -q $rpm >/dev/null 2>/dev/null") ) { system("rpm -e $rpm"); oscar_log_subsection("Removing $rpm RPM"); } }
This should be deleted; we now handle this via distro-specific lists.
my $pqtv = `rpm -q --quiet --qf '%{VERSION}' perl-Qt 2>/dev/null`; if ( $pqtv && $pqtv < 3 ) { !system("rpm -e perl-Qt") or warn("Couldn't remove perl-Qt"); oscar_log_subsection("Removing perl-Qt RPM"); }
As you can see, this code is a problem for Debian.
These too. There's a lot of direct references to rpm(1) that should be depman/packman references. There are also various other code bits that are just plain ugly less-than-excellent distro-dependent hacks that need to be replaced.
For example, with Debian, I am using /tftpboot/deb instead of /tftpboot/rpm
and I also need to setup some specific Debian stuff. So I put this kind of
stuff in the check_local_repository.
But to summarize, the organization of the install_cluster script is: * [...] * check the local repostository
OK
* check the status of some basic packages (tftp, tftpserver)
As noted above, should be deleted.
* ...Etc.
Unfortunately, the current code of these two steps is RPM based.
check_local_repository and remove_pkg allows to have a generic code for
such
scripts.
Let's be careful and use the depman/packman abstraction correctly (i.e., the current 4.1 doesn't yet do this) before creating others. We also need to make sure the code is still correct (as noted above), and takes advantage of advanced capabilities that we now have. The same comments apply to remainder of the email...
Bottom line, I'm all for this, but we need to fix correct code instead of fixing code that is not.
-- David N. Lombard
My comments represent my opinions, not those of Intel Corporation.
------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id5hix _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
-- {+} Jeff Squyres {+} [EMAIL PROTECTED] {+} http://www.lam-mpi.org/
------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id5hix _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
