Pet packages vs. SFS files (Solved)

Booting, installing, newbie
Post Reply
Message
Author
User avatar
Argolance
Posts: 3767
Joined: Sun 06 Jan 2008, 22:57
Location: PORT-BRILLET (Mayenne - France)
Contact:

Pet packages vs. SFS files (Solved)

#1 Post by Argolance »

Bonjour,
Why the same program, with exactly the same contents, sometimes works as pet package and does not as SFS file!!! :shock:
Do someone know what's the reason of such a strange behavior and if possible, how this could be solved?
Examples:
  • - Flowblade works fine when installed as pet but complains about missing "mlt" when loaded as SFS (note that this program needs Python 2.7 which is in the devx or as stand alone basic package).
    - Seamonkey works as pet and not as SFS.
    - ...
NOTE: I am running Puppy Precise 5.7.1.

Merci.
Cordialement.
Last edited by Argolance on Wed 01 Nov 2017, 08:54, edited 1 time in total.

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#2 Post by Mike Walsh »

Morning, Argolance.

I currently have somewhat limited understanding of this. Don't quote me on the subject, but I believe it's to do with the different ways in which a .pet package and an SFS package interact with Puppy.

Puppy's unionfs 'layering' system sees .pets and SFS's rather differently. From what I can gather, installing a .pet will 'overwrite' & replace any file of the same name. Loading an SFS, however, is like putting a sticky label over the top of a file, then writing the same name on it. When you unload the SFS, you remove all those additional labels.....but the originals are still there underneath.

And due to this layering, etc., some files are 'seen' following installation of a .pet, where the SFS package doesn't seem to 'present' those same files in such a way that they're 'noticed'. I think this has something to do with the way in which files from one 'layer' can sometimes show through 'windows' in the layer above. That's from BK's own explanation of all this:-

http://barryk.org/puppylinux/developmen ... works.html

.....which is rather 'heavy' reading, unless you're genuinely interested in all this kind of stuff!

Mine is a very poor explanation, but it's the best way I know how to put it. Hopefully, somebody else can explain it better than me..!


Mike. :wink:

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#3 Post by nic007 »

Yes, pets load to the top layer and takes preference over the base sfs (for similar files). If you use a newer puppy that support the adrive and ydrive (like tahr), you can rename the problematic sfs file to that of the adrv or ydrv and it should load on top (have preference to) the base sfs at bootup. This should work if there is no other conflicts present in your savefile or savefolder (because the savefile/folder is at the very top as far as preference is concerned).

User avatar
bigpup
Posts: 13886
Joined: Sun 11 Oct 2009, 18:15
Location: S.C. USA

#4 Post by bigpup »

This is more about what version of the program, what dependency files are needed and their versions, and what core Puppy files are there and their versions.
You can make a pet or SFS package, but that does not make it correct just because you made it.
Part of making a program package is what version(s) of Puppy it will work in.
A good SFS package is made with all necessary stuff in the package.
Even if it requires adding new core files or programs.
There is a packaging art, to making a SFS package, that will work on many many Puppies.
Could also do this with a pet package, but usually a pet is just the program.
That is why Puppy has the program Check Dependencies Installed Packages. That will tell you if that specific package needs something else to make it work.

Simple example:
Make a Graphics driver pet or SFS package.
Because of how graphics drivers are used.
That pet or SFS package will only work with one specific Linux kernel.
If that specific kernel, is not being used by the Puppy version, the driver will not work.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected :shock:
YaPI(any iso installer)

User avatar
Argolance
Posts: 3767
Joined: Sun 06 Jan 2008, 22:57
Location: PORT-BRILLET (Mayenne - France)
Contact:

#5 Post by Argolance »

Hello guys,
Thank you. :)
Mike Walsh wrote:Puppy's unionfs 'layering' system sees .pets and SFS's rather differently. From what I can gather, installing a .pet will 'overwrite' & replace any file of the same name. Loading an SFS, however, is like putting a sticky label over the top of a file, then writing the same name on it. When you unload the SFS, you remove all those additional labels.....but the originals are still there underneath.

And due to this layering, etc., some files are 'seen' following installation of a .pet, where the SFS package doesn't seem to 'present' those same files in such a way that they're 'noticed'. I think this has something to do with the way in which files from one 'layer' can sometimes show through 'windows' in the layer above.
Here is probably the explanation...
What is strange indeed is that Seamonkey as SFS is not working whatever release loaded! SFS-load says my file is truly loaded but absolutely nothing of the contents of the SFS file appears, namely, /usr/lib/seamonkey!!! :oops:
bigpup wrote:You can make a pet or SFS package, but that does not make it correct just because you made it [...]
Note that this SFS file is built from the same directory used to build the pet package (which works perfectly), in the same environment i. e. Puppy Precise 5.7.1... This happens only with Seamonkey. None of the multiple other SFS files I have created has this behavior, except Flowblade (which doesn't see mlt, present however in the loaded devx file).

Cordialement.

User avatar
bigpup
Posts: 13886
Joined: Sun 11 Oct 2009, 18:15
Location: S.C. USA

#6 Post by bigpup »

except Flowblade (which doesn't see mlt, present however in the loaded devx file).
Is the devx SFS the first one to load in the SFS package load list?
Does it load before the Flowblade SFS in the load list?
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected :shock:
YaPI(any iso installer)

User avatar
Argolance
Posts: 3767
Joined: Sun 06 Jan 2008, 22:57
Location: PORT-BRILLET (Mayenne - France)
Contact:

#7 Post by Argolance »

Is the devx SFS the first one to load in the SFS package load list?
Does it load before the Flowblade SFS in the load list?
The first thing I do when I run a new session is to load my devx... So Flowblade or any other SFS file is always loaded after.

I just downloaded the latest release of Seamonkey ( 2.48 ). If I run it directly from the directory where I just decompressed the tar file, it works fine and immediately. If I build the SFS file replacing the old /usr/lib/seamonkey directory with the new one, I get the same issue: this directory does not appear in /usr/lib.
Could this be something originally wanted by BK, when Seamonkey was the unavoidable Puppy default web browser?

theru
Posts: 163
Joined: Thu 23 Jul 2015, 16:40
Location: Heers, Belgium

#8 Post by theru »

Did you install/uninstall the seamonkey pet to update the builtin seamonkey before trying out the seamonkey sfs?

If you did you can have issues with file layers (save layer lies on top) or whiteout files (hide files in sfs layer).

User avatar
OscarTalks
Posts: 2196
Joined: Mon 06 Feb 2012, 00:58
Location: London, England

#9 Post by OscarTalks »

I don't know about flowblade but with SeaMonkey in Precise I think Mike Walsh's explanation was correct. When you load a .sfs package it goes underneath the main puppy .sfs in the layered file system. Since Precise has a directory at /usr/lib/seamonkey this will hide the one in your .sfs package. In fact /usr/lib/seamonkey is a symlink to the original seamonkey directory which has a number on the end of it.

You could do a work-around by naming the directory something different in the .sfs package you create, eg seamonkeyNEW. Then after loading the .sfs, delete the symlink /usr/lib/seamonkey and create a new one with the same name, but linking to the new seamonkeyNEW directory. There are other ways you could do it I am sure, so long as you understand the basic issue that any file or directory of the same name and in the same location will be hidden by the one in the main puppy layer. In the case of a .pet package the layer goes over the top which is why the behaviour can be different.
Oscar in England
Image

theru
Posts: 163
Joined: Thu 23 Jul 2015, 16:40
Location: Heers, Belgium

#10 Post by theru »

@OscarTalks: thanks for the information. I always assumed sfs files were added between the base sfs and the savefile but according to the how puppy works page they are added to the bottom of the stack. Since the /usr/lib/seamonkey folder (which is actually a symlink) already exists in the base sfs it will only been replaced if that happens in the savefile.

It's not too difficult to check if the seamonkey sfs is loaded. I use slimjet as an example:

Code: Select all

losetup -a | grep slimjet
/dev/loop6: 0 /initrd/mnt/dev_save/tahr64/slimjet-11.0.1.0-amd64-tahr.sfs
mount | grep loop6
/dev/loop6 on /initrd/pup_ro6 type squashfs (ro,noatime)
So my slimjet sfs is mounted at /initrd/pup_ro6

User avatar
Argolance
Posts: 3767
Joined: Sun 06 Jan 2008, 22:57
Location: PORT-BRILLET (Mayenne - France)
Contact:

#11 Post by Argolance »

Bonjour,
theru wrote:Did you install/uninstall the Seamonkey pet to update the builtin seamonkey before trying out the seamonkey sfs?
If you did you can have issues with file layers (save layer lies on top) or whiteout files (hide files in sfs layer).
You are right, I installed/uninstalled Seamonkey's pet package before trying to load the SFS file. I already made tests the same way some times ago and I am coming back to this issue because I want to understand how and why this happens. This morning, I ran a new session and loaded Seamonkey as SFS file and... it worked!

I tried Flowblade too with the devx loaded first, after, but mlt is not found! Made symbolic links here and there, without success.

Something is sure now: the 2 problems are due to 2 different causes.

Cordialement.

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

#12 Post by mikeslr »

Hi Argolance,

Which version of Flowblade are you using? Have you installed any applications which may conflict with it? Running Precise, I had a 'mlt' problem when I had openshot loaded. See here and the posts following: http://www.murga-linux.com/puppy/viewto ... 267#822267. And I've run across posts on the Web indicating that KDEnlive also could conflict. Both of those applications employ python and mlt which may conflict with the Flowblade's python and mlt.

But, I think it goes beyond those two applications and has to do with the 'layering' problem you've previously discussed. I see that you are obtaining python by loading the devx sfs. My recollection is that battleshooter's versions of Flowblade discussed in the above post and here, http://murga-linux.com/puppy/viewtopic. ... 915#751915, had python built in. Loading devx to obtain python wasn't necessary and, in fact, may conflict.

Alternatively, since flowblade is an SFS, any version of python which was included in the original build of Precise, or which got installed into your SaveFile (as a component of some pet) would take precedence over the version included in flowblade.

mikesLr

User avatar
Argolance
Posts: 3767
Joined: Sun 06 Jan 2008, 22:57
Location: PORT-BRILLET (Mayenne - France)
Contact:

#13 Post by Argolance »

Bonjour,
mikeslr wrote:Which version of Flowblade are you using?
The release I am using is the 0.16.0 and it seems that Python directories are present inside.
Making it run as SFS file without devx in a new session... and it works!
Silly I am: don't know where I noticed that the devx Python was needed. :shock:
Unfortunately, it may cause other problems with other programs using python too: this is a little bit robing Peter to pay Paul! :)
Indeed, the best would be a Flowblade package without its own Python and working with the Puppy Precise + the devx: everybody would be happy!

Note that download links given in the thread above are dead...

Thank you a lot!

Cordialement.

User avatar
Mike Walsh
Posts: 6351
Joined: Sat 28 Jun 2014, 12:42
Location: King's Lynn, UK.

#14 Post by Mike Walsh »

@Argolance:-

Battleshooter's stuff is now being 'hosted' by Russoodle over at archive.org. Seems it was among the stuff that was saved when meownplanet went down a couple of years ago.....though as I understand it, a lot of stuff was lost forever. (Unless, of course, Ally managed to mirror any of it for posterity.)

Explore the archive here:-

https://archive.org/download/Russoodles ... tleshooter

You'll find his 'Flowblades' there. Also, KDEnlive & Openshot.


Mike. :wink:

User avatar
Argolance
Posts: 3767
Joined: Sun 06 Jan 2008, 22:57
Location: PORT-BRILLET (Mayenne - France)
Contact:

#15 Post by Argolance »

Thank you a lot. :D

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

#16 Post by mikeslr »

Argolance wrote:...
Making it run as SFS file without devx in a new session... and it works!
...
Unfortunately, it may cause other problems with other programs using python too: this is a little bit robing Peter to pay Paul! :) ...
That's one of the advantages of SFSes. They are not installed, so don't overwrite the files needed by other applications. If there's a conflict, you just unload the problem SFS (may require a reboot).

FWIW, the potential problem doesn't exist under Xenialpup64. There's a flowblade.appimg. It's self-contained. So, if you have enough RAM, you can run openshot (or KDEnlive) and avidemux pets at the same time as flowblade. Pretty much a video editor's tool kit.

mikesLr


Post Reply