Portable-AppImage-TAR maintenance

[Clarity]

Each distro provides a mechanism for adding applications to its foundational base system. It is maintained, adequately, in its Package Management (PM) subsystem. There are, though, several other 'accepted' options for adding applications to a system.

Request: Your ideas for maintaining Portables, AppImages, TARs, SFSs, Flatpaks, etc.

Scenario
I have a portable that I want to add to the system's behavior; say one of the browser portables. 2 things:

• I would like to have a folder reference point for these kinds of additions.

• And, I would like to know where to link the utility within the distro's filesystem.

• Same would be done for all such additions to the system outside of the distro's PM such that they can be callable at any time.

According to your understanding of the Linux Architecture and some common base of Linux's filesystem; where in the filesystem linkage would you recommend these be linked such that it is clear that they are 'subsystem-application additions' beyond distro's PM?

Looking for ideas. Want to consider methods for Good Housekeeping of additions beyond the scope of the PM.

P.S. Free free to recommend external folders that would be containers for the links in the running directory architecture, as well. Please understand that this question set has nothing to do with compression/encryption of external folders; merely allocation benefit for referential housekeeping.

Hope this request for your ideas or recommendations does not confuse.

[Clarity]

Each distro provides a mechanism for adding applications to its foundational base system. It is maintained, adequately, in its Package Management (PM) subsystem. There are, though, several other 'accepted' options for adding applications to a system.

Request: Your ideas for maintaining Portables, AppImages, TARs, SFSs, Flatpaks, etc.

Scenario Example
I have a portable that I want to add to the system's behavior; say one of the browser portables. 2 things:

• I would like to have a folder reference point for these kinds of additions.

• And, I would like to know where to link the utility within the distro's filesystem.

• Same would be done for all such additions to the system outside of the distro's PM such that they can be callable at any time.

According to your understanding of the Linux Architecture and some common base of Linux's filesystem; where in the filesystem linkage would you recommend these be linked such that it is clear that they are 'subsystem-application additions' beyond distro's PM?

Looking for ideas. Want to consider methods for Good Housekeeping of additions beyond the scope of the PM.

P.S. Free free to recommend external folders that would be containers for the links in the running directory architecture, as well. Please understand that this question set has nothing to do with compression/encryption of external folders; merely allocation benefit for referential housekeeping.

Hope this request for your ideas or recommendations does not confuse.

[mikewalsh]

@Clarity :-

I can't quite see what you're driving at, mate. Can you expand upon what you mean by a "folder reference point", please?

I mean, the direction I've taken with the 'portables' is to include scripts which, when clicked upon, will add/remove a Menu entry. Depending upon the application, it gets put where you would expect to find an application of its category. The name for each of these Menu entries has '-portable' appended to it, so you know exactly what you're dealing with.....though in all honesty, whether an app IS 'portable' or not has no bearing upon its functionality.

Each portable's 'LAUNCH' script is linked into /usr/bin, and the .desktop entry in /usr/share/applications then calls it, just like it would with any other application.

I don't think I could be bothered to make the effort to keep ALL portables together in a specific part of the Menu. Where would be the point in doing so?

I can only assume that thee and me have different ideas as to how Menus should be organised!

P.S:- If you unpack any of my portable packages, and study some of the scripts, etc, it's quite easy to see what I've done. Very simple & straight-forward, really.

Mike.

[Clarity]

Hi Mike, I am looking more at folder to keep portables within; not a change to the PUPPY Menu.

Your approach to appending "Portable" has been an excellent approach.

But, my concern is when we consider the Linux file-systems architecture with its supported folder and the intent of those folders, is there a folder/place within the architected filesystem structure where one might consider proper housekeeping for placing references of ones portables.

Not seeking a change in Puppy/Linux; rather ideas that if an existing folder hierarchy exist, where one might consider keeping Portables (the portables might actually be in location outsider of the Linux hierarchy and the contents are symbolically-linked to that hierarchy folder idea within the architecture I am referencing for ideas)

Example: I have a storage folder on a system drive called Portables. I wonder if there is a place within the LInux filesystem architecture that I can sym-link the portables for housekeeping search reference. This is NOT a request for the portable's execution, rather it is a request for housekeeping. And when opening that folder, I can see the portables that are saved even thought the actually contents are outside of the Linux standard.

Would a good idea to place a new folder for such under /usr or under / opt or /media or ??? Just consider ideas based on our understanding of the missions of the Linux filesystem architecture.

Does that give a better view of the request?

[mikewalsh]

@Clarity :-

Mm. Yes, I see what you're getting at.

To be honest, the place I would sym-link the directory into would be /opt.....this having always been a "catch-all" location for most things that don't readily fit anywhere else.

There is, of course, no reason why said directory couldn't be linked directly into / itself, i.e., /Portables. Myself, I tend to maintain external directories full of this kind of thing.....the corollary being that I either use the .desktop entry associated with the sym-linked 'LAUNCH' script in /usr/bin, or - what I often do with things that may get moved around - is to use a 'fixed' .desktop entry (which always references a 'fixed' script, usually in /root/my-applications/bin).

The beauty of this approach being that you can easily modify the exec line within that script, without having to run 'fixmenus' + restart JWM, etc. Nothing changes except the contents of the script that point to the app's executable.....and that change is immediate.

I understand the 'good house-keeping' approach very well, though I merely maintain links to the executables for every portable. Those are the only links I keep within the system, since I, personally don't want an 'internal' link to an entire directory.....not for these. That's the idea of the add/remove MenuEntry scripts; it gives you a direct start link to whatever the app in question happens to be, without needing to link it into the system in any other way.

Of course, once you have a .desktop entry, you can drag it onto the desktop, add it to the QuickLaunch area near the Menu button, or do anything else with it that you want.

Does that give you any ideas?

Mike.

[Clarity]

Yes, I had considered placing a folder in /opt as a location, but wanted to ask others who also understand the Linux filesystem for their views. Also it would continue referable across reboots.

Thanks for helping and sharing.