Here is the situation:
I have a .pet package created with dir2pet. The name is "test-1.0.pet".
Inside of this .pet package are 2 files and 2 sym-links
/root/test-1.0/etc/gtk/etc-gtk.xpm (file 1)
/root/test-1.0/usr/etc/gtk/usr-etc-gtk.xpm (file 2)
/root/test-1.0/root/etc-gtk.xpm (sym-link 1)
/root/test-1.0/root/usr-etc-gtk.xpm (sym-link 2)
Sym-link 1 is a relative link to file 1 and likewise with sym-link 2.
When this package is installed ONLY 3 of the 4 above items get installed!
File 2 does NOT get installed. You can test this out for yourselves with the attached file.
Even though file 2 does NOT get installed, it still shows up in the file...
/root/.packages/test-1.0.files
as being installed!
I get exactly the same results with both Puppy 3.01 AND Puppy 2.14 with a frugal install. Other tests have led me to believe that this is an 'undocumented feature' of Pupget. It seems that everytime Pupget encounters a sym-link (directory) when installing a file, the file goes into the bit-bucket (never to be seen again) instead of the specified path. We could of course suggest to Puppy users to NEVER create a .pet in which the file destination path is through a sym-link.
A very common path amongst most Linux develpers for over 10 years is "/usr/lib/X11/app-defaults/FILENAME" and Petget won't install to this location either becasue it is sym-linked.
I certainly hope that I am in error about this.
W2K
Petget (undocumented feature?)
Petget (undocumented feature?)
- Attachments
-
- test-1.0.pet
- Test file to duplicate my observations.
- (657 Bytes) Downloaded 638 times