[arch-general] KDE4.3 Beta - Rocks, still a bit rough, but very usable as a primary desktop [SOLVED]

[David C. Rankin]

On Wednesday 17 June 2009 14:00:54 David Rosenstrauch wrote:
> David C. Rankin wrote:
> > 	I know all the warning about not using -f, but after reviewing the
> > conflicts being icons and other misc. files, I decided it was time for
> > the 'nuclear option'. So I reared back and let the following fly:
> >
> > 	pacman -Sy -f kde kde-extragear
> >
> > and just hit return, return, return, return until it started installing.
>
> Just my $0.02, but bad idea.  I'd think it's quite possible that you'd
> wind up with stray files hanging around by forcing pacman like this.
> It's never a good idea to leave system/app files hanging around that
> pacman doesn't know about, since you can wind up with weird file
> conflicts down the road.
>
> DR

	I agree whole heartedly and I am a 100% advocate of "Don't do it unless you 
are absolutely sure what you are doing and what the results will be." It is 
the same philosophy that applies to rpm's --force option. So, in this case did 
I follow the rule?

(1) Not a production box, Arch install isolated on a spare raid partition, all 
files (including Arch packages) backed up, nothing critical at risk.

(2) The objective. To test and evaluate the installation of kde-unstable on 
the box while leaving kdemod3 installed.

(3) The issue preventing a clean pacman install without -f: -- 20440 lines of 
conflicting icons, .desktop files, the same .so files, etc. repeatedly listed 
as a conflict for each package because 2 packages make use of them. (something 
just looks funny there)

(4) The downside if it all goes wrong -- pop the arch disk in the tray; 
reboot; fdisk /dev/mapper/nvidia_ecaejfdi; then d, d, d, w; reboot and 
reinstall. (all the packages are already saved locally so reinstall isn't a 
painful download away)

	So sticking to the rule, I knew exactly what I was doing and knew exactly 
what the results would be (...within a slight range so to speak;-)

	But, seriously, I'm not real sure pacman is thinking correctly on this kde-
unstable install. I don't have kde4 installed, but it looks like it sure 
thinks I do. Take for example the conflicts listed just with regard to "kate". 
(A standard package, not overly complex, but big enough to provide an example) 
The conflicts in the attachment to keep the lines from wrapping).

	All of the conflicts are of the form:

application.h exists in both 'kdesdk-kate' and 'kdesdk'

	To which the logical answer is "yes, I know, it is supposed to, right?". What 
I don't understand is why should you have to either uninstall kdesdk-kate or 
kdesdk to make pacman happy? Even if you remove both, after you install then 
application.h exists in both 'kdesdk-kate' and 'kdesdk' -- again. 

	And, if I force the install of a new application.h that will exist in both 
'kdesdk-kate' and 'kdesdk' again anyway -- what's the harm?

	Following the install, I tested with an update to see the result. The first 
time it installed 15 or so packages and replaced whatever pacman thought was 
kde4 with kde4-unstable:

:: Starting full system upgrade...                                                                                                          
:: Replace kdeaccessibility with kde-unstable/kde-meta-kdeaccessibility? [Y/n]                                                              
:: Replace kdeadmin with kde-unstable/kde-meta-kdeadmin? [Y/n]                                                                              
:: Replace kdeartwork with kde-unstable/kde-meta-kdeartwork? [Y/n]                                                                          
:: Replace kdebase with kde-unstable/kde-meta-kdebase? [Y/n]                                                                                
:: Replace kdebindings with kde-unstable/kde-meta-kdebindings? [Y/n]                                                                        
:: Replace kdeedu with kde-unstable/kde-meta-kdeedu? [Y/n]                                                                                  
:: Replace kdegames with kde-unstable/kde-meta-kdegames? [Y/n]                                                                              
:: Replace kdegraphics with kde-unstable/kde-meta-kdegraphics? [Y/n]                                                                        
:: Replace kdemultimedia with kde-unstable/kde-meta-kdemultimedia? [Y/n]                                                                    
:: Replace kdenetwork with kde-unstable/kde-meta-kdenetwork? [Y/n]                                                                          
:: Replace kdepim with kde-unstable/kde-meta-kdepim? [Y/n]                                                                                  
:: Replace kdeplasma-addons with kde-unstable/kde-meta-kdeplasma-addons? [Y/n]                                                              
:: Replace kdesdk with kde-unstable/kde-meta-kdesdk? [Y/n]                                                                                  
:: Replace kdetoys with kde-unstable/kde-meta-kdetoys? [Y/n]                                                                                
:: Replace kdeutils with kde-unstable/kde-meta-kdeutils? [Y/n]                                                                              
:: Replace kdewebdev with kde-unstable/kde-meta-kdewebdev? [Y/n]                                                                            

	Then running it again, all was well:

[14:37 archangel:/etc/php] # pms -u                                                                                                         
:: Synchronizing package databases...                                                                                                       
 kdemod-legacy is up to date                                                                                                                
 kde-unstable is up to date                                                                                                                 
 core is up to date                                                                                                                         
 extra is up to date                                                                                                                        
 community is up to date                                                                                                                    
 archlinuxfr is up to date                                                                                                                  
:: Starting full system upgrade...                                                                                                          
 local database is up to date                                                                                                               

	I'll keep an eye on it, but in working with it for a while, I think we're 
good.

-- 
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com