Erich,
This seems reasonable but my only concern is the "smart" part. My two main
concerns about this are:
1) How good a job can we do with resovling and ultimately removing
conflicting packages and possibly their dependents packages.
The PVM example is pretty easy but I can quickly see things like
tftpboot causing problems b/c of slight naming difference, etc.
2) As much as I hate hardcoded lists, it is nice to be able to see
exactly what is going to be removing (or attempted). I mention
this b/c the fact that we're dorking with things someone as *already*
installed (possibly indirectly by some "default" install) makes my
a bit twitchy to begin with. ;)
However, I see that we need something. Geoffroy and I were chatting about
a Sanity framework (i hope to writeup and post soon) and from that
discussion we thought of possibly having also an Initialization framework,
not very far on those details though. I could see these "remove pkg foo"
items going well into an Initialization framework...thoughts????
Anyway, I'll think more about your approach and see what I think...above
was pretty much knee-jerk-reaction. :)
Thanks,
--tjn
_________________________________________________________________________
Thomas Naughton [EMAIL PROTECTED]
Research Associate (865) 576-4184
On Wed, 7 Dec 2005, Erich Focht wrote:
Hi Thomas,
today's email from Paul Greidanus shows that we have a general problem with
preinstalled RPMs. We cannot expect that somebody cleans up the master node
before doing the OSCAR install. So my proposed solution for PVM (rename the
package to pvm-oscar) is bad and not applicable for all the RPMs we have.
This looks like we should check for every RPM of a package and resolve each
conflict sometime between generic-setup and server install step. Something
like:
is the package marked as installed in the oscar database?
yes : skip the rest
no :
detect package names involved in current opkg
smartly remove them from the host (master)
Just an idea...
Regards,
Erich
On Friday 02 December 2005 22:41, Thomas Naughton wrote:
Hi,
I'm just now getting a chance to test oscar-trunk, and discovered the
issue/saw this thread. ;)
I will update the 'setup' script to make use of the 'generic-setup'
mechanism but I think I still want to do the work of uninstalling any
existing PVM versions.
As for renaming the package 'pvm' vs. 'pvm-oscar'. Well, I'm actually in
the process of trying to merge the "pvm3.spec" into the main PVM src tree.
Once I get some things cleaned up I hope that at least it will live *in*
the tarball somewhere so that I don't have to have a seperate "oscar"
version. This doesn't address distro-rebuilds but I think that the version
of PVM that we (oscar) distribute will always be the latest/greatest.
Also, the distros typically put PVM in a standard directory, e.g., "/usr/bin/"
AFAIK. This causes problems if you have that installed and try to use
OSCAR's version which gets PATH'd via Modules.
I'm open to thoughts about not removing the existing PVM, but I'll have to
be convinced that keeping a distro installed PVM is better than using what
OSCAR provides. ;)
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Oscar-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
