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

Reply via email to