How to include a new app in current sfs or new sfs.

[Mike3]

So, I wanna include new apps into the old sfs files that were included in install like: "puppy.sfs / adrv.sfs / zdrv.sfs" and the like or in a new sfs.

How do I do this?

I know how to do the unsquashfs and mksquashfs thing but where in an existing sfs should I place the files for an app?

And if I install an app with the PPM how can I move it to the sfs. And how do I make sure the app symbol in the menu is linked to the right files to start the app?

Is it best to use an existing sfs such as the adrv.sfs or zdrv.sfs or a new one?

[mikewalsh]

@Mike3 :-

If it were me, I would unsquash the SFS to a work directory; add every component for the new app manually into its correct location, followed by re-building the SFS again. You'll need to run

Code: Select all

ldd 

.....against the binary or executable component of the new app in order to see what's missing. These are the items that will need tracking down and adding to the SFS; there's no point in adding stuff that doesn't list as "not found", either because it's already there in the 'base' install, OR because you've added it yourself through installing something else. An extremely useful resource for tracking all this stuff down is pkgs.org.

There may be a way to use PaDS for this, but personally I have zero experience of it; t'other Mike, mikeslr, is the one to get advice from where this is concerned.

Different Puppians do things in different ways.....and there aren't always tools/utilities available for automating absolutely everything. Sometimes things just have to be done in the time-honoured "manual" way.

-------------------------------------------

Most things tend to get created/compiled/built/packaged in Puppyland as a result of the "do-ocracy" principle; if somebody wants/needs something for whatever reason, AND they feel capable of putting such a package together, then they will usually go right ahead & do it. I don't know of anyone in our community who builds & packages stuff because they feel they should, or because they feel compelled to, OR because they feel it's their "duty" to do so.

We don't have a dedicated team of individuals who spend all their time maintaining package repos for everyone else, so that's how WE get round the issue.....invariably, whatever is being "shared" is because the individual sharing it uses it regularly themselves, and wants others to have the benefit. And there again, many of us find we enjoy building/packaging software to share, because we got so much help from the community in our own "noob" phase, so it's our way of paying the community back for all that help.

Puppy positively encourages this "share and share alike" attitude..!

Mike.

[mikeslr]

So, I wanna include new apps into the old sfs files that were included in install like: "puppy.sfs / adrv.sfs / zdrv.sfs" and the like or in a new sfs.

How do I do this?...

Install nicOS-Utility-Suite, viewtopic.php?p=12983#p12983, a suite of tools designed to do just what you are asking about. See the graphic on that post.

First step is to know which file system in storage holds the application. Mount each and look in /opt and in /usr/share/applications.

The Remasters modules will change the content of your puppy.sfs: removing applications if you've already used Menu>Setup>Remove Builtin [which doesn't actually remove them from the file-system on storage]; and include in the new puppy.sfs applications you've installed to your SaveFile/Folder.

Save2SFS will do the same to create a new adrv.sfs (or a ydrv.sfs or both, one at a time). Both will also include in a new a/ydrv.sfs applications you've installed but not yet Saved.

Save2SFS is easy to use if you are adding applications or updating them. But it doesn't remove applications from either an adrv.sfs or a ydrv.sfs. Ask if you're interested.

A ydrv.sfs has priority over the contents of puppy.sfs.
An adrv.sfs has priority over both the contents of the puppy.sfs and the ydrv.sfs
The way I use these modules is:
Remaster to include updates of applications I always want to have and delete applications I'll never want.
Create an ydrv.sfs to include applications I always want which are 'alien' to my puppy: alien -- built using files not available via PPM or otherwise easily available to your Puppy. A later remaster will not affect the ydrv.sfs (or an adrv.sfs).
Create an adrv.sfs to hold web-browsers and other applications which are frequently updated.

[Mike3]

So, where does new apps installed with the PPM end up?

Are they automatically put by the PPM in the adrv.sfs / zdrv.sfs and so on files?

If I create a new ydrv.sfs file with for example the new apps there, would that be automatically loaded on startup?

How do I make it so that the app is started from the meny by clicking it's icon? Do I need to link files in e certain way or something, to make it so that the icon being clicked starts the app now located in the main puppy.sfs or ydrv.sfs?

Or are the apps located in the _drv.sfs location automatically saved to the places in the system where it needs to be to be found and run when clicking it's entry in the meny?

@mikewalsh...

You write:

add every component for the new app manually into its correct location

How do I know what the correct location in an SFS file is based on it's location outside the sfs's?

And then regarding the

Code: Select all

ldd

thing, is that run from terminal. Do one just write ldd and then the name of app's binary file, like:

Code: Select all

ldd /usr/bin/netscape

if it is the netscape webbrowser I wanna do this with?

So do I need to put all the files that the app needs or is dependent on also in the sfs file to make it work? And is this what I find with the

Code: Select all

ldd

command?

I looked and most of the binary files of apps that are in the main puppy.sfs seems to be located in /usr/bin

And this seems to be where the binaries from the newly installed apps not in an sfs file are also located so from this I assume that some files from the main puppy.sfs are autimatically copied or moved from the main puppy.sfs to: /usr/bin when one starts up the OS is this correct? And if so, where in the .sfs files are the files that are copied/moved to

I now have my webbrowser run from spot. Would it be possible to store it in an .sfs file but still have it run from spot? How would I make this work?

[mikewalsh]

@Mike3 :-

O-kay. Can I make a suggestion here?

It may seem like a backwards step to you, but for a Puppy beginner you do seem to be trying to jump in at the deep end awfully quickly. It'll stand you in good stead - seriously! - if you do what I guess many of us have done at some point in the past; take a little bit of "time out" to read up on exactly how the Linux file-system works, why it's constructed the way it is, and the reasons for WHY items are put where they are.

If you don't fully understand what all the different directories and sub-directories are for, it's pointless trying to charge straight in to package building/modification. There's a ton of tutorials out there, but this one is better at explaining than many, because it also uses images:-

https://www.howtogeek.com/117435/htg-ex ... explained/

--------------------------------------

Puppy contains all the actual packaging materials already; scripts, binaries, utilities, etc.....these come with every Puppy, OOTB. The majority of packaging utilities that are available for the community usually make use of these, but attempt to present them in an easy-to-use way.

Most of us who package stuff for the community learnt our "craft" the same way every Puppian before us did; largely by trial & error. True, most of us have 'automated' what we do to streamline things, but we've usually written those automation scripts, too, to suit our own individual use-case.

When I started with Puppy nearly a decade ago, I, too, asked exactly the same 1001 noob-type questions as everyone else. Some of us take in what we've learned; others seem to keep asking the same old questions, over & over again, never really learning anything. The degree of interest plays a large part; if you're interested enough in something, and want to do it badly enough, you'll go out of your way to try and learn. It's not for everyone, though in my own case I found out it was something I enjoyed, and turned out be quite proficient with.

It's like everything, Mike; you have to learn to walk before you can run.

Mike.

[Feek]

So, where does new apps installed with the PPM end up?

During automatic installation in PPM, the package is downloaded, then installed, but the package as such is not preserved.
In PPM you can set not only the automatic installation of a certain package, but there are also other options.
I'm not in Puppy with PPM right now, but I think there's a drop-down bar at the top of the PPM next to the search box.
There you can set the package to be downloaded and saved.
So after downloading you can extract it and then it will be a folder (directory). For example, the UExtract tool can be used to extract it.
And subdirectory surfing should tell you where the right place is for all items.

[mikeslr]

Hi Mike3:
Many questions – one post. Much confusion. In the future try to break them up such as asking about spot in a different post.

Short Version:
All puppys published in the last 6 +/- years will use an adrv.sfs and/or a ydrv.sfs if it/they are located next to your puppy.sfs. YOU WILL STILL NEED THE zdrv.sfs and any fdrv.sfs. Their contents will not be in the new adrv.sfs or ydrv.sfs.
Save2SF is an alternative way of preserving the current state of your system to Saving to changing the contents of your SaveFile/Folder or remastering your puppy.sfs. If that current state has a menu entry, the preserved state will have a menu entry.

Save2SFS gives you the choice of whether to include an existing adrv.sfs in a new ydrv.sfs. It gives you the choice of just creating an adrv.sfs. Which means you’ll still need your old ydrv.sfs. Depending on the choices you make running Save2SFS, you may be able to delete or move your old adrv.sfs or ydrv.sfs.
Delete or Move. After creating a new adrv.sfs or ydrv.sfs your SaveFile/Folder is no longer necessary. You can delete it. But its safer to move it either out of your Puppy’s folder or into a folder –I name mine ‘protect’-- in your Puppy’s folder so that it is at a lower level than your Puppy's System Files. If you’ve moved it and something went wrong you can retrace your steps and get back to where you were without having to start from scratch. A SaveFile/Folder is READ-WRITE. Moving them while in use can damage them. To move or copy them you have to boot ‘pfix=ram’. Or you can create a backup before you run the Save2SFS application.

Longer Version and ListDD:

You have a frugally installed Puppy. For a technical explanation of how it works, see viewtopic.php?p=55827#p55827. This is my layman’s understanding leaving out some technical details such as how Puppys make use of inodes, caching and buffering to manage files in RAM.
A location in RAM can only be occupied by one file. When it is possible for two or more files to occupy that location instructions in your operating system determine which competing file is to occupy that location.
A frugal Puppy uses a ‘merge-file-system’ creating anew, on boot-up, in RAM your working operating system by reading into RAM the contents of those file-systems (SFSes) you have on your storage medium: Puppy.sfs, ydrv.sfs and adrv.sfs in that order, overlaying one on top of the other so that you only can use the top layer if its contents covers something on lower layers. Kind of like using layers in a graphic program: you only see what’s on top.

On boot-up Puppy also copies into RAM the contents of a zdrv.sfs (drivers to communicate with hardware) and, if present, fdrv.sfs (firmware also needed to communicate with hardware). Sometimes both drivers and firmware are provided in the zdrv.sfs. As their files are in unique folders, their contents do not ‘cover’ each other or any other file which makes up your operating system in RAM.

When and if you’ve have a SaveFile or SaveFolder, on boot-up its contents are NOT copied into RAM. Rather, it is mounted and links to its content are created in RAM. Those links have the second highest priority; 2nd only to the files you’ve later installed or modified in RAM. You are always operating in RAM.

[Application SFSes –such as LibreOffice.sfs-- are handled the same way as your SaveFile/Folder: mounted with links to its content created in RAM. Application SFSes, however, have lower priority than the contents of your SaveFile/Folder. AppImages and portables are handled similarly with only links to their content in RAM. AppImages are mounted when you click them].

Your operating system, including all the applications it can use, are files in RAM, or can be pulled into RAM through the links in RAM.

When you install a pet (or other package) initially its contents are only in RAM. Its contents will ‘overwrite’ in RAM any conflicting files which had been copied into RAM, and overwrite any link to mounted file-systems’ files. But that application is only in RAM. RAM is cleared when shutdown/reboot finishes. So if you shutdown without Saving the application which was only in RAM and its contents are gone. On the other hand, if before or during shutdown you execute a Save, the contents in RAM are written to your SaveFile/Folder.

[While operating there’s a folder named /tmp in RAM to which files temporarily needed are written. The Save application has instructions not to save anything in the /tmp folder].

The nicOS-Utility-Suite creates another option. Its Save2SFS module can create a new adrv.sfs and/or a new ydrv.sfs. Creating a new adrv.sfs will capture the contents of your old adrv.sfs; a new ydrv.sfs will capture the contents of your old ydrv.sfs and (optionally) your old adrv.sfs. Either will capture the contents of your SaveFile/Folder and any application (and settings and configuration files) already in RAM, even if not yet Saved. Neither will capture the contents of /tmp folder.

Neither a creating a SaveFile/Folder, nor creating a new ydrv.sfs nor a new adrv.sfs alters the contents of an fdrv.sfs or a zdrv.sfs. YOU WILL STILL NEED THEM. It’s just that –if you installed other drivers or firmware-- they will be in the SaveFile/Folder, or ydrv.sfs or adrv.sfs depending on which technique you’ve used to preserve that addition to your system. And, as aforesaid, those files systems have priority in your 'merged in RAM file-system': so the other drivers or firmware will be part of your 'merged in RAM file-system'.

About files in an SFS: an SFS is a (squashed) file-system. If you mount it you can see its structure and can file-browse into folders to see the files and folders it contains. Those files are in locations where a Linux operating system expects to find files of that type. The pets or packages you install already have their files in the proper locations. The same is true of SFSes. Installing a pet merely copies files from the pet into its corresponding place in RAM. Loading an SFS merely creates a link in the proper place in RAM to the file on storage. [Which is why pets and SFSes built for 64-bit Slackos don’t always work in ‘Ubuntus’ and vice-versa: they expect some files to be in different locations].

You are correct. Most binaries are in /usr/bin. But not all. If it’s not there, this is how I use ListDD when examining a file-system I’ve mounted or copied such as when working with an adrv.sfs. File-browse to /usr/share/applications and look for the desktop file of the application. It’s Exec= argument gives the name, sometimes the location of the file which starts the application. If the location wasn’t given, within the folder I am examining I Right-Click an empty space, select Windows>Shell Command and type pfind. When pfind opens I click the Current button, then type the name from the Exec= argument. The report will find every file in the ‘Current Folder’ having that name. The file which starts the application will be in a folder named bin or sbin. File-browse to that folder. The file will be a binary, a symbolic link to the binary or a bash-script calling the binary. If a bash-script, you’ll have to open it in a text editor and read it to find the binary. If its a symbolic link, Right-Click it and select Show Target from the pop-up menu. When you finally find the binary, Right-Click it and select ListDD from the pop-up menu.
No one said that this will always be easy.
Because you are working with a ‘merge-file-system’ the only files you have to include in an SFS are those not otherwise found on your system. If you’re not sure, it won’t hurt to include a file. Only one will be used by the merged-file-system.

“I now have my webbrowser run from spot. Would it be possible to store it in an .sfs file but still have it run from spot? How would I make this work?” Please start this question in its own thread unless the following answers your question. When you have an application running as spot and modify the system by Saving to a SaveFile/Folder or capturing the contents of RAM to a new adrv.sfs or ydrv.sfs the application which previously ran as spot will still be ‘run as spot’ in your modified operating system.

[bigpup]

So, where does new apps installed with the PPM end up?

Normal operation of a Puppy version installed as a live or frugal install.
Anything downloaded by PPM and installed goes into the save file/folder.
Anything added, setting changes, etc... are stored in the save.

When Puppy boots the stuff stored in the save is layered into the operating file system and becomes part of it.

How Puppy works:
viewtopic.php?t=5818