dotpet: functions to work with .pet files

Under development: PCMCIA, wireless, etc.
Post Reply
Message
Author
jlst

dotpet: functions to work with .pet files

#1 Post by jlst »

dotpet: functions to work with .pet files

I think it's pretty generic, but requires bash4.. I'm using bash 4.3.30 (source package)

Use this script only in test .pet files/directories
Use a test puppy install (*)

It gets really tiring trying to explain this in detail.. feedback is welcome

usage (1):

Code: Select all

. dotpet
function parameters
function2 parameters
etc
usage (2):

Code: Select all

dotpet function paramaters
dotpet function2 paramaters
etc

dotpet pet_raw_filelist <file.pet>
dotpet pet_filelist <file.pet>
dotpet pet_filelist2 <file.pet>

dotpet pet_check <file.pet>
dotpet pet_has_file <file.pet>
dotpet pet_extract <file.pet>
dotpet pet_extract2 <file.pet> [like a normal tar file]
dotpet pet_extract_file <file.pet> <file>

dotpet pet_specs <file.pet>

dotpet pet2tar <file.pet>
dotpet tar2pet <file.pet>

dotpet unpet2root <file.pet> (*)


MASS PROCESSING
---------------
dotpet dir_pet_has_install <dir>
dotpet dir_pet_has_uninstall <dir>
dotpet dir_pet_has_specs <dir>
dotpet dir_pet_specs <dir>

dotpet dir_pet_filelist <dir>
dotpet dir_pet_filelist2 <dir>
dotpet dir_pet_check <dir>

dotpet dir_pet_extract <dir>
dotpet dir_pet_extract2 <dir>

dotpet dir_pet2tar <dir>
dotpet dir_tar2pet <dir>

dotpet dir_unpet2root <dir> (*)
Attachments
dotpet-0.1-any.pet
(3.58 KiB) Downloaded 220 times

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#2 Post by mavrothal »

Very interesting!
So the command to install a single pet is

Code: Select all

dotpet unpet2root /path/to/pet/name.pet
Is full path needed?
How do you remove a single or all user installed packages?

Are you thinking to expand it to handle deb and slack packages?
Checking and warning for any missing dependencies?
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

jlst

#3 Post by jlst »

mavrothal wrote:Very interesting!
So the command to install a single pet is

Code: Select all

dotpet unpet2root /path/to/pet/name.pet
Is full path needed?
How do you remove a single or all user installed packages?

Are you thinking to expand it to handle deb and slack packages?
Checking and warning for any missing dependencies?
This is how the script handles <file.pet> and other <files>

if <file.pet> is /path/to/file.pet , then it's used as is

if <file.pet> is file.pet, then it becomes $PWD/<file.pet>
if <file.pet> is dir/file.pet, then it becomes $PWD/dir/<file.pet>
if <file.pet> is ./file.pet, then it becomes $PWD/<file.pet>

if <file.pet> is ../file.pet or another strange path the result is a wrong path

To answer your question, I can make similar scripts for: debian/slackware/arch linux. Something like dotdeb dotslack dotarch

It is a lot of work and I need testers

Uhmm this script can be considered a "building block". So it shouldn't install, but I added that function to test if it does a proper install.

Install something and try to uninstall with PPM....

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#4 Post by mavrothal »

jlst wrote:To answer your question, I can make similar scripts for: debian/slackware/arch linux. Something like dotdeb dotslack dotarch

It is a lot of work and I need testers
Sure is, but people may want something more "complete" to start testing. Specially something without GUI may have even less testers if "too fundamental".
If the aim is to evolve to a full feature cli package manager, a la apt-get or pacman or yam then it may worth putting some more "complete" (pre-) alpha versions out to trigger wider testing. Something that can user can type "dotpet install emacs" and actually do it (most of thetime 8) )

I think is on the right track for that. It basically needs to link to the download_file (or equivalent) and have a db search option that can determine which package the user is really trying to get.
Dependencies would be a bit more difficult but still. The logic is already there (in PPM and other PMs)

Uninstalling should be really simple to implement.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#5 Post by jamesbond »

mavrothal wrote:Uninstalling should be really simple to implement.
Hahaha :lol: Nothing is simple with puppy. :lol:

I don't mean that in bad meaning or to discourage contribution. Puppy is *easy* to use from the users point of view - but underneath is quite complex (this statement is actually true for many things - an automatic car is easier to drive than a manual one but the more complex to implement, etc). I just want to bring appreciation and attention to the fine workings under puppy's foundation; so budding puppy developes don't underestimate the underlying complexity of the deceiving simplicity you see from the top. I've been biten by the same issues in the past, so my intention is simply to give a road post for people who are taking the same path so they don't have to learn the hard way.

Uninstallation in puppy is complex because of its layered filesystem. Removing a pet that previously overwrote files from its lower layer (basesfs, or any other sfs really) leaves whiteout files which means that any other SFS loaded after the uninstall, which provides the same file, will fail. Case in point: you have qt4.sfs loaded. Then you accidentally install a bad.pet that contains qt4 too, in the same path. That blows up the rest of your qt4 apps, so you decide to uninstall this bad.pet. Uninstallation removes everything, and leaving whiteout files so that files provided by qt4.sfs is no longer visible, no matter how many times you load or unload the sfs. End-result: frustrated user. BK's petget code have logic to avoid this situation. Not perfect, but good enough for most situation. Anybody taking over petget need to be aware of this.

And of course, BK's petget also have a surprise for installation too. If you're running pupmode=13, .pet installation files will to straight to the pup_save file instead of the RAM layer. This allows you to install (for illustration only) 1GB.pet on a 512MB machine as long as your savefile/savefolder has more than 1GB free. You can't do that if you just un-tar the whole shebang to /.

When I re-wrote my script, I can afford to play fast and loose because I'm not writing it for puppy. If you are writing puppy replacement script, however, you need to aim for full compatibility, and these are just one of the few things that you need to be aware of. Or you can start by saying that "these features are now no longer supported..." :wink:
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#6 Post by mavrothal »

jamesbond wrote:
mavrothal wrote:Uninstalling should be really simple to implement.
Hahaha :lol: Nothing is simple with puppy. :lol:
I considered pointing to the whiteouts but then thought that is better to get deep in to the process before the uphill :twisted:
But still removing pets is easier than the complexity of installing them in all different modes including "rescuing" clobbered files in full installs.
But all these after the alpha is out :wink:

Puppy indeed does too many things that "should not be happening in a normal distro" and usually gets little appreciation from users and a lot of criticism from developers for these exact things. :roll:
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

Post Reply