Hi Thomas, the more I think about it the less I see a clean general solution.
The simple variant proposed by Bernard: rpm -e all packages from an opkg before installing might break often because of the order of dependencies. Putting all package removals in one rpm command will only work if there are no other packages depending of one of these rpms. Counterexample: some perl-* package we install with some opkg might already come installed in a distro version and have other packages installed on top of it (depending of it). You won't be able to remove it. The smart package manager I propose (say apt, yum) would remove all packages in an opkg, including any packages depending on them. So If the user installed something on purpose which needs perl-*, this thing will be gone after the OSCAR install. I could live with it, but it's not good. The scripted apporach you seem to propose avoids the ordering problems in the simple case, but cannot overcome the issue with the perl-* package which is installed with an opkg. Should it be removed, too? What if there are other packages depending on it (outside the opkg)? Besides, the scripted approach is really hard to maintain. So here is yet another idea. It somehow plays together with the cleanup thing we are discussing on the other mailing list. The opkg components can be separated in useful add-on packages (the ones you really want) and in dependencies and prerequisites you usually don't care about but you need to install because of the important add-on packages. For example: systemimager* are the packages doing the work while perl-AppConfig is just a helper/dependency. If we find a way to mark and separate these, we could decide to only care about the worker packages, so delete them before installing an opkg. The helpers/dependencies should just be updated, if needed, but otherwise not touched. I'd expect that the worker packages are mostly at the end of a dependency tree, so they should be removed without problems. But well, there seems to be no obvious easy way... Regards, Erich On Wednesday 07 December 2005 19:10, Thomas Naughton wrote: > 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
