DraftSight new CAD program also for Linux install problem

[wedgetail]

kjpetrie
Thanks, I accept that when I remove the application that I can no longer be sure the system is 'clean'.  I will make a note, in my install log for this system, and when something goes funny hopefully I will remember to look in the log to remind me.  This is why I normally try to run anything oddball in a sacrificial install, the result of which I have many installs and get confused as to what I am actually running and what I think I am running.  

When I try to run the DraftSight it fails but I think this has something to do with registration. You have 30 days free trial without a simple registration and I seem to remember receiving an email about the need for re-registering. I did that according to the email but I don't think I got confirmation so I just assumed that the registration would be working.

Since a new version has been made available I have downloaded a copy and I have set up a new KDE32 based on platform 4.8.3 or the 2012.08 ISO fully updated then installed Opera before attempting to install DraftSight. For my own record I will come back and write this up as I had trouble getting the new version running but when my attention was lowest I had success and can now use this for 30 days without having to register.

When I get time to test a few drawings and find it is ok I will try and register this latest version.

                      

[wedgetail]

The present perceived problem with DraftSight not working does seem to have something to do with registration.  After Google started working after a number of days being almost unusable I did a bit of googling on:

Code: [Select]

This product is not licensed or has expired DraftSight
Since I have not heard back on my registration request I decided that I would try to uninstall via Synaptic the original first version of DraftSight that I downloaded. Nothing really to loose as I could not use it. My hope was that somehow the registration was left behind (seem to be indicated by a Windows user who had recovered operation my uninstalling and then reloading the latest version).

KDE Platform 4.6.5
I think this turns out to be correct because when on my old DraftSight version, on KDE Platform 4.6.5, was uninstalled and the new DraftSight rpm installed, the program now works from the PC > Graphics > DraftSight.  I do not get the normal invitation to register or run for 30 days free. I am delighted with this as I have an awful lot of drawings sitting here.  Another challenge are now facing me, which I will come back to below.

KDE32 Platform 4.8.3
I prepared a new KDE32 4.8.3 install, fully updated and then installed Opera ie a system with very little contamination by me   When I tried to install DraftSight V1R3 Beta, the latest download it did not install. Seemed to go through the motions looking at the konsole output during the install.

[root@localhost 111125-DraftSight_CAD]# rpm -ivh file:///media/DELTA-10/111125-DraftSight_CAD/121024-draftSight.rpm
Preparing...                ########################################### [100%]
   1:dassault-systemes-draft########################################### [100%]

mkdir: cannot create directory `//.local': Permission denied
touch: cannot touch `//.local/share/applications//mimeapps.list': No such file or directory
/usr/bin/xdg-mime: line 607: //.local/share/applications/defaults.list.new: No such file or directory
grep: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 609: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 611: //.local/share/applications/defaults.list.new: No such file or directory
mv: cannot stat `//.local/share/applications/defaults.list.new': No such file or directory
Set application as default for the user=gert
Set application as default for the user=nobody
mkdir: cannot create directory `//.local': Permission denied
touch: cannot touch `//.local/share/applications//mimeapps.list': No such file or directory
/usr/bin/xdg-mime: line 607: //.local/share/applications/defaults.list.new: No such file or directory
grep: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 609: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 611: //.local/share/applications/defaults.list.new: No such file or directory
mv: cannot stat `//.local/share/applications/defaults.list.new': No such file or directory
Set application as default for the user=gert
Set application as default for the user=nobody
mkdir: cannot create directory `//.local': Permission denied
touch: cannot touch `//.local/share/applications//mimeapps.list': No such file or directory
/usr/bin/xdg-mime: line 607: //.local/share/applications/defaults.list.new: No such file or directory
grep: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 609: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 611: //.local/share/applications/defaults.list.new: No such file or directory
mv: cannot stat `//.local/share/applications/defaults.list.new': No such file or directory
Set application as default for the user=gert
which: no sestatus in (/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin)
[root@localhost 111125-DraftSight_CAD]#

This looks to be an unlikely successful install but past experience indicates it may be ok.

There are a few options how to test, I think my favorite now is to have quik look in /opt and if the following is seen then chances are promising.

[root@KDE-mini gert]# ls -l /opt
total 24
drwxr-xr-x 3 root root 4096 Oct  2 18:33 dassault-systemes/
drwxr-xr-x 3 root root 4096 Mar  1  2010 lib/
drwxr-xr-x 7 root root 4096 Aug 24  2011 libreoffice3.4/
-rw-r--r-- 1 root root   27 Mar  1  2010 mms.cfg
drwxr-xr-x 3 root root 4096 Mar  1  2010 share/
drwxrwxr-x 5 gert gert 4096 Sep  2  2010 VariCAD/
[root@KDE-mini gert]#

The red line here indicates that something has been installed.  Now it is worse pursuing to find the run exec.  My experience with the latest program has been that it nows seem to install an Icon in the graphics section of the PC menu and this will work properly in the present user space. The old program seemed to have a problem as it wanted to run in root space. Well for me at least and this is what now present a real challenge for me.

First though on this platform, my install attempt appeared to have failed. I did not find any "dassault-systems" line in /opt. I went through the motion of updatedb and locate DraftSight and found nothing, the last I use to find the the exec file if the Icon starter not available but the system is installed.

Since nothing would be lost I tried two things, rpm -ivh --force ..... and removing my date indicator, 121024-..... in front of the file name use in the install:

[root@localhost 111125-DraftSight_CAD]# rpm -ivh --force file:///media/DELTA-10/111125-DraftSight_CAD/121024-draftSight.rpm

I am not sure which load item caused the success I ran them sequentially before checking.  After this /opt does have the expected line. DraftSight now runs as a new install on this KDE32 Platform 4.8.3, I am presented with the 30 day free trial and invitation to register by supplying my/an email address.  I am leaving the registration til late in the period, I do want however to make this system the CAD systems only. Will later add VariCAD 3D system here too.  So all is fine here.

The problem of permissions:
The original DraftSight system in my case ran as root basically and for me this resulted in all my data files now sitting in root space.

[root@KDE-mini gert]# ls -l /root
total 32092
-rw-r--r-- 1 root root 32768000 Feb  7  2012 120207-ram.bin
-rw-r--r-- 1 root root       66 Feb  8  2012 99-primary_partition_table_1.bin
drwxr--r-- 2 root root     4096 Mar 24  2011 Desktop/
drwxr-xr-x 3 root root     4096 Jan 13  2012 Documents/
drwxr-xr-x 2 root root     4096 Feb 19  2010 Downloads/
drwx------ 2 root root     4096 Jan  9  2011 drakx/
drwxrwxrwx 4 root root     4096 Nov 27  2011 draw/
-rw-r--r-- 1 root root        8 May 21 20:13 lp
drwxr-xr-x 6 root root     4096 Jan 17  2012 mulinux/
drwxr-xr-x 2 root root     4096 Feb 19  2010 Music/
-rw-r--r-- 1 root root     1034 Sep  4  2011 OpenDNS_howto.txt
drwxr-xr-x 2 root root     4096 Apr 13  2010 Pictures/
drwxr-xr-x 2 root root     4096 Feb 19  2010 Templates/
drwx------ 5 root root     4096 Oct 26 12:17 tmp/
-rw-r--r-- 1 root root    32768 Feb  8  2012 usb-backup-cylinder1.bak
drwxr-xr-x 2 root root     4096 Oct 20  2010 Videos/
-rw-r--r-- 1 root root      109 Apr 14  2012 w_scan.log

[root@KDE-mini gert]# ls -l /root/draw
total 8
drwxr-xr-x 3 root root 4096 Dec  5  2011 DraftSight_Gert_Testing/
drwxr-xr-x 2 root root 4096 Nov 27  2011 Qcad-Gert_Testing/
lrwxrwxrwx 1 root root   24 Jun 21  2011 VariCAD Samples -> /opt/VariCAD/lib/sample//
[root@KDE-mini gert]#

I need some help to move these files out of present root environment , to user gert and thus visible to DraftSight when this runs under user gert

So far I always get something wrong when trying to move from root to user. I end up using a mixture of konsole and konqueror/dolphin operation to get the properties and permissions right and that only for a few files albeit also moved across partition boundaries.

First: how do I safely move the whole /root/draw directory over to user space so that all files and subdirectories then show gert:gert in ls -l statements?  

[kjpetrie]

In a terminal, as root:

Code: [Select]

# mv /root/draw /home/gert/
# chown -R gert:gert /home/gert/draw

Alternatively, open a file manager in superuser mode, ensure the /home/gert folder is visible in the folder list, then open /root and drag the draw folder to gert. When asked what to do select move. (Double) click /home/gert and right click draw. Select the permissions tab and change the owner and group to gert. Tick the box to apply the change to all files and subdirectories and click OK.

[wedgetail]

kjpetrie
Thank you, the two code lines was what I am looking for. The option -R had slipped my mind (again). I enjoy working in konsole when the going gets tough.  

Here I also tried root Konqueror to do a copy (just to be sure I would not loose the content) and discovered something (for me interesting). I forgot to tick the "subdirectories"  but soon found out and just repeated the process with the tick but to my surprise this did not seem to "fix" the user:group change. I have not had time to follow up on this, so I just quickly went to this position:

/home/gert/draw/DraftSight_Gert_Testing/Acad_Data_Recovered_Gert/

and tried again changing user:group with subdirectories ticked.  This worked I now have gert:gert to the bottom level of the directory hierarchy.

Just to repeat, this is the program version:  rpm DraftSight for Fedora®, Suse® or Mandriva® (Beta V1R3) ,  I now have running both in:

1.. KDE-mini Platform 4.6.5 and it seems to be registered as it gives no warning about expiry

2.. KDE32 Platform 4.8.3 but requires registration, I get nag screen with warning I have only 27 days left.

Since I am now working on this install situation I have looked a bit at the konsole output, it intrigues me that despite apparent looking failures the rpm seems to install, though I think when Synaptic happens to be open it will halt just before the mkdir .... until Synaptic is closed before continuing.  This is probably fair enough.


Regarding root konsole install report

[root@localhost 111125-DraftSight_CAD]# rpm -ivh file:///media/DELTA-10/111125-DraftSight_CAD/121024-draftSight.rpm
Preparing...                ########################################### [100%]
   1:dassault-systemes-draft########################################### [100%]

mkdir: cannot create directory `//.local': Permission denied
touch: cannot touch `//.local/share/applications//mimeapps.list': No such file or directory
/usr/bin/xdg-mime: line 607: //.local/share/applications/defaults.list.new: No such file or directory
grep: //.local/share/applications/defaults.list.new: No such file or directory
....
......

The blue line above I am having trouble understanding.  It seems to me that the line says: root can not run mkdir //.local this has me rattled as there is no higher authority than root??

In a root konsole I did manually run that statement and it seemed ok but it was after a couple of aborted installs. Since I manually ran the statement this may be why below I have an empty /.local directory.

Below shows that I do have a /.local but now I am further stuck as the statements use //.local..., ie. there is an extra /

[root@localhost gert]# ls -l /.local
total 0
[root@localhost gert]# cd /.local
[root@localhost .local]# ls
[root@localhost .local]#

Well there is a /.local and it is very empty. It is like a treasure hunt, there are clues but I can't decipher yet.

In short I am really stuck and confused    

[Archie]

You cannot run two instances of apt, i.e. apt-get. If you run an apt-get command on a terminal with Synaptic opened at the same time, the terminal session will not finish the command until the GUI is closed. It is normal behavior.

Not sure if my logic and interpretation of // is correct but it would simply mean the highest folder in the hierarchy which is the /. It is like cd // = change directory to folder /. Try it with cd //etc or cd //usr or cat //etc/fstab.

[wedgetail]

Archie
Your post broke me free of going around circles.  I will just accept that Synaptic can not be open when I run rpm -ivh whatever_rpm_file. I understand that Synaptic is a GUI form of apt-get and the rpm -ivh.... need access to the rpm database and Synaptic also wants to talk to the same database. This causes a stand off,  ok that will do me.  

I had a light bulb moment, since I had not manually run mkdir //.local here, I went back to KDE Platform 4.6.5 DraftSight and checked the root file system for /.local and it is non existent, from that I conclude that my manual attempt on KDE32 Platform 4.8.3  to run mkdir //.local did work, this also makes sense, to me, then that this directory is empty. The install program did not produce the directory.

I checked out on using // in few instances, and you are right, to me it seems it does not really matter if one uses / or // in konsole statements.

[root@localhost gert]#
[root@localhost gert]# cd //
[root@localhost //]# ls -a
./   .autofsck  boot/  etc/   home/    lib/     lost+found/  mnt/            null  proc/  sbin/  swap/  there/  usr/
../  bin/       dev/   here/  initrd/  .local/  media/       Module.symvers  opt/  root/  srv/   sys/   tmp/    var/
[root@localhost //]# cd /
[root@localhost /]# ls -a
./   .autofsck  boot/  etc/   home/    lib/     lost+found/  mnt/            null  proc/  sbin/  swap/  there/  usr/
../  bin/       dev/   here/  initrd/  .local/  media/       Module.symvers  opt/  root/  srv/   sys/   tmp/    var/
[root@localhost /]#

So my conclusion here is that // is valid when encountered.

To me this seems to leave the question why can the rpm exe file when running under root not create a directory //.local ??  That would be right up your alley??

[Archie]

Simply because the folder already exist. There should have been a check to see if a folder exist. If it exist, two things can happen - either rm -rf //.local and recreate it again or skip the mkdir and else to the next step/command.

I would suggest that you # rm -rf //.local before running the binary again.

[wedgetail]

Archie
The existence of the directory unfortunately seems to have no influence on the out come.  The reason I have the directory at all in KDE32 version is that my thinking was if I make the directory first then surely it will work. So the sequence was.

1.. On a fresh KDE32 I did the rpm -ivh ... and nothing installed.
2.. After thinking a bit I forceloaded  with rpm -ivh --force ...
3.. Now it gets a bit more tricky but I think I did the mkdir //.local in desparation
4.. Immediately forceloading again
5.. Then I checked the /opt directory and saw the tell tale addition.

I believe that in each case the konsole result is almost the same.

Since I am getting this stubborn feeling,  so I am prepared to run up yet another virgin KDE32 system and repeat more carefully at what stage it starts working.  Any advice on how I can see what actually gets modified when I install?  I have been force loading hoping that nothing new outside the actual rpm would be changed, as against actually un-installing first and re-installing the rpm.

The easiest would be to gamble and just carry on with this KDE32 experimenting and if it goes bust too bad.

1.. Remove /.local as you suggest and then force load again, if the program still runs, the most I might loose is a few custom settings which I am still trying to refresh my acquaintance with.

2.. Uninstall carefully with Synaptic, only the rpm, and I may also look at the rpm -ivu ...

3.. Install again

I think I will do this.

[Archie]

When installing # rpm -Uvh file:///media/DELTA-10/111125-DraftSight_CAD/121024-draftSight.rpm I noticed that one of the instructions from the binary was to mkdir //.local and this could not be completed because the hidden folder already exist which is why it is throwing an error but the instructions did not sidetrack the existence of the hidden .local folder and the subsequent commands like touch //.local/share/applications//mimeapps.list cannot be completed.

Try it out, you have nothing to lose by removing the folder and let the binary run its course of instructions.

[wedgetail]

Archie
KDE32 Platform 4.8.3

Removing the //.local directory, using root konsole::

[gert@localhost ~]$ su
Password:
[root@localhost gert]# ls -al /.local
total 8
drwxr-xr-x  2 root root 4096 Oct 24 23:09 ./
drwxr-xr-x 25 root root 4096 Oct 27 15:03 ../

[root@localhost gert]# ls -al //.local
total 8
drwxr-xr-x  2 root root 4096 Oct 24 23:09 ./
drwxr-xr-x 25 root root 4096 Oct 27 15:03 ../
[root@localhost gert]#

Yes the directory is there, nothing in it. Tested using both / and //

[root@localhost gert]# rm -rf //.local
[root@localhost gert]#

[root@localhost gert]# ls -al //.local
ls: cannot access //.local: No such file or directory
[root@localhost gert]#

The directory no longer exists

[root@localhost gert]# rpm -Uvh file:///media/DELTA-10/111125-DraftSight_CAD/121024-draftSight.rpm
Preparing...                ########################################### [100%]
        package dassault-systemes-draftsight-2012.7.340-2.i386 is already installed
[root@localhost gert]#

Hmmmm, this did not do it.  Guess this is fair enough.  I forgot to mention I think, that this was one of the main reasons why I decided to use the --force option, so here we go::

[root@localhost gert]# rpm -Uvh --force file:///media/DELTA-10/111125-DraftSight_CAD/121024-draftSight.rpm
Preparing...                ########################################### [100%]
   1:dassault-systemes-draft########################################### [100%]
Set application as default for the user=nobody
mkdir: cannot create directory `//.local': Permission denied
touch: cannot touch `//.local/share/applications//mimeapps.list': No such file or directory
/usr/bin/xdg-mime: line 607: //.local/share/applications/defaults.list.new: No such file or directory
grep: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 609: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 611: //.local/share/applications/defaults.list.new: No such file or directory
mv: cannot stat `//.local/share/applications/defaults.list.new': No such file or directory

Set application as default for the user=gert
Set application as default for the user=nobody
mkdir: cannot create directory `//.local': Permission denied
touch: cannot touch `//.local/share/applications//mimeapps.list': No such file or directory
/usr/bin/xdg-mime: line 607: //.local/share/applications/defaults.list.new: No such file or directory
grep: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 609: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 611: //.local/share/applications/defaults.list.new: No such file or directory
mv: cannot stat `//.local/share/applications/defaults.list.new': No such file or directory

Set application as default for the user=gert
Set application as default for the user=nobody
mkdir: cannot create directory `//.local': Permission denied
touch: cannot touch `//.local/share/applications//mimeapps.list': No such file or directory
/usr/bin/xdg-mime: line 607: //.local/share/applications/defaults.list.new: No such file or directory
grep: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 609: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 611: //.local/share/applications/defaults.list.new: No such file or directory
mv: cannot stat `//.local/share/applications/defaults.list.new': No such file or directory
Set application as default for the user=gert
which: no sestatus in (/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin)
[root@localhost gert]#

Checking for the //.local again
[root@localhost gert]# ls -al //.local
ls: cannot access //.local: No such file or directory
[root@localhost gert]# ls -al /.local
ls: cannot access /.local: No such file or directory
[root@localhost gert]#

DraftSight  runs fine, I just checked, still have my customised menu system in here.  Not sure if I can conclude that this:: rpm Uvh --force file_in_question in this case is the same as rpm ivh --force file_in_question I believe it may be but I am going to try that as well.

Since I expect rpm ivh --force file_in_question to be the same I will just record the output from konsole in my log and not bother copying it here.

Did I miss something you were trying to explain?   

Next step I am going to uninstall.

[wedgetail]

I have uninstalled via Synaptic, I was not too sure if rpm -evh file_in_question would do.  I have recorded some details from synaptic in my log and I was going to find the dependencies to DraftSight run command but my brain failed again, don't remember, thought it might have been ldd

Having removed the DS rpm file I did look for 'left overs'

[root@localhost gert]# updatedb
[root@localhost gert]# locate DraftSight
/home/gert/.config/Dassault Systemes/DraftSight.conf
/home/gert/tmp/DraftSight__autosave
/home/gert/tmp/DraftSight__temp
/home/gert/tmp/DraftSight__autosave/111126-Gert_Learning_04_Backdoor_drain_3439.ds$
/home/gert/tmp/DraftSight__autosave/NONAME_0_3405.ds$
/home/gert/tmp/DraftSight__temp/gl_info.txt

/root/.config/Dassault Systemes/DraftSight.conf
/root/tmp/DraftSight_gert_autosave
/root/tmp/DraftSight_gert_temp
/root/tmp/DraftSight_gert_temp/gl_info.txt
[root@localhost gert]#

I now think I understand why I did not loose my DS custom menus when I uninstalled DS, rather nice too. I also assume that is the reason why when I uninstalled the older DS Beta on KDE Platform 4.6.5 and then loaded the latest DS here again that my registration for that version was sitting in one of those files.  Handy to know.

Notice that I accidentally started up a root session of DS, I was trying out

[root@localhost gert]# ldd /opt/dassault-systemes/draftsight/bin/draftsight
        not a dynamic executable
[root@localhost gert]#

[root@localhost gert]# ls -al  /opt/dassault-systemes/draftsight/bin/draftsight
-rwxr-xr-x 1 root root 812 Oct  2 18:33 /opt/dassault-systemes/draftsight/bin/draftsight*
[root@localhost gert]#

[root@localhost gert]# /opt/dassault-systemes/draftsight/bin/draftsight
version = 12.7.340

Hmmmm, not getting anywhere understanding why why the mkdir //.local gets Permission denied, unless it has something to do with the previous line about user=nobody. 

It looks like that each time user=nobody line shows there will be a problem with Permissions.   

[Archie]

OK. Since it is already install and is not getting the update, uninstall the package and make sure /.local is not created. Make sure what the package name is using the rpm -qa | grep draftsight

# rpm -evf packagename

Then reinstall it again. The point is if you allow it to create the //.local folder, it will be able to proceed with the rest of the instruction to complete a successful installation.

[wedgetail]

Archie
Sorry I stuffed up a bit in my previous post, I mentioned that I had uninstalled  DraftSight via Synaptic. Then it got a bit confusing for any reader. I also got sidetracked trying to find rpm tools, found it is called rpmxdgtools which I have installed.

I know from experience now that having uninstalled and then done updatedb followed by locate DraftSight that there will be very few files left with DraftSight in the name, in this case I only found about 6 remnants in user:gert and about 4 in user:root. This means the uninstal was successful.

Here I got sidetracked talking about how I could see why another install would pick up my old custom menu settings and apply this to a new install. 

I then reinstalled: rpm -ivh file_in_question the konsole output is unchanged, no //.local created but DraftSight works again.

Following confirms that no directory created, I will now stop doing the double check, using / and //, just one of them after this:

[root@localhost gert]# updatedb
[root@localhost gert]#


[root@localhost gert]# ls -al //.local
ls: cannot access //.local: No such file or directory

[root@localhost gert]# ls -al /.local
ls: cannot access /.local: No such file or directory
[root@localhost gert]#

As you can see after the install no //.local directory.

I will now repeat the exercise exactly as you suggest and see if that changes the result.   

[wedgetail]

Oooops, made a mistake and think I have stuffed the rpm database, must look up the repair statement but:

[root@localhost gert]# rpm -qa | grep draftsight
dassault-systemes-draftsight-2012.7.340-2
[root@localhost gert]#

Just having finished dinner I was dreaming absentminded while doing the  # rpm -evf packagename

I did:

[root@localhost gert]# # rpm -evf /media/DELTA-10/111125-DraftSight_CAD/121024-draftSight.rpm
[root@localhost gert]# ls -al /opt
total 36
drwxr-xr-x  9 root root 4096 Oct 27 16:07 ./
drwxr-xr-x 24 root root 4096 Oct 27 17:48 ../
drwxr-xr-x  3 root root 4096 Oct 27 16:07 dassault-systemes/
.........

Seeing the blue line I woke up and realised something was wrong so I did.

[root@localhost gert]# # rpm -evf dassault-systemes-draftsight-2012.7.340-2
[root@localhost gert]# ls -al /opt
total 36
drwxr-xr-x  9 root root 4096 Oct 27 16:07 ./
drwxr-xr-x 24 root root 4096 Oct 27 17:48 ../
drwxr-xr-x  3 root root 4096 Oct 27 16:07 dassault-systemes/
.........................

Time for panic, the last blue line should not be there.

Opened Synaptic and found DraftSight, but highlighting the file did not bring details, it seems stuck.

Conclusion: I have stuffed the rpm database     I only remember there is a way to rebuild it but I don't remember. I will go searching but if anybody feels like having pity on me, I will be grateful. 

[wedgetail]

I found the rpm rebuild:

[root@localhost ~]# rpm -vv --rebuilddb

Then had a real scare, turned out to be one of those silly mistakes, forgot to remove the # from Archie's command to remove the an rpm file.  Back on track again.

[root@localhost gert]# rpm -evf dassault-systemes-draftsight-2012.7.340-2
[root@localhost gert]#

[root@localhost gert]# updatedb
[root@localhost gert]# ls -al /opt
total 32
drwxr-xr-x  8 root root 4096 Oct 27 21:10 ./
drwxr-xr-x 24 root root 4096 Oct 27 17:48 ../
drwxr-xr-x  3 root root 4096 Aug  8 19:35 google/
drwxr-xr-x  3 root root 4096 Mar  1  2010 lib/
drwxr-xr-x  8 root root 4096 Jul 28 10:53 libreoffice3.6/
drwxr-xr-x  3 root root 4096 Mar  1  2010 share/
drwxr-xr-x  3 root root 4096 Aug  8 20:21 teamviewer/
drwxr-xr-x 11 root root 4096 Jun 28 04:42 VirtualBox/
[root@localhost gert]#

[root@localhost gert]# ls -al //.local
ls: cannot access //.local: No such file or directory
[root@localhost gert]#

No //.local and nor DraftSight in /opt

Installing DraftSight again:

[root@localhost gert]# rpm -ivh //media/DELTA-10/111125-DraftSight_CAD/121024-draftSight.rpm
Preparing...                ########################################### [100%]
   1:dassault-systemes-draft########################################### [100%]
Set application as default for the user=nobody
mkdir: cannot create directory `//.local': Permission denied
touch: cannot touch `//.local/share/applications//mimeapps.list': No such file or directory
/usr/bin/xdg-mime: line 607: //.local/share/applications/defaults.list.new: No such file or directory
grep: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 609: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 611: //.local/share/applications/defaults.list.new: No such file or directory
mv: cannot stat `//.local/share/applications/defaults.list.new': No such file or directory
Set application as default for the user=gert
Set application as default for the user=nobody
mkdir: cannot create directory `//.local': Permission denied
touch: cannot touch `//.local/share/applications//mimeapps.list': No such file or directory
/usr/bin/xdg-mime: line 607: //.local/share/applications/defaults.list.new: No such file or directory
grep: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 609: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 611: //.local/share/applications/defaults.list.new: No such file or directory
mv: cannot stat `//.local/share/applications/defaults.list.new': No such file or directory
Set application as default for the user=gert
Set application as default for the user=nobody
mkdir: cannot create directory `//.local': Permission denied
touch: cannot touch `//.local/share/applications//mimeapps.list': No such file or directory
/usr/bin/xdg-mime: line 607: //.local/share/applications/defaults.list.new: No such file or directory
grep: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 609: //.local/share/applications/defaults.list.new: No such file or directory
/usr/bin/xdg-mime: line 611: //.local/share/applications/defaults.list.new: No such file or directory
mv: cannot stat `//.local/share/applications/defaults.list.new': No such file or directory
Set application as default for the user=gert
which: no sestatus in (/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin)
[root@localhost gert]#

[root@localhost gert]# ls -al //.local
ls: cannot access //.local: No such file or directory
[root@localhost gert]#

DraftSight runs from Icon in PC > graphics > DraftSight

Hmmm, think I will leave it here for a while.