-
-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"AM" 8.1 #894
Conversation
ivan-hc
commented
Aug 28, 2024
- allow "AppMan" to be installed/used outside "$HOME", by @Samueru-sama
- allow "AM" support for distro packagers
allow appman to work outside `$HOME` take 2
improve detection of `$BINDIR` APP-MANAGER
fix conversion of old appman config APP-MANAGER
Fix appman mode usage in AM for unprivileged users
Update CONTRIBUTING.md
The piece that must be changed to made distro packagers bundle "AM" is this
The only variable interested to this support is "MODULES_PATH", the one containing the modules. Note that the change wants you to rename the script APP-MANAGER to "am", if you want to put it in /usr/bin as /usr/bin/am All depend on how you want to install AM into a distro package. it would be sufficient to change the above behaviour like this
what it does is to check if the command "am" is /usr/bin/am "AMPATH" is needed to determine the directory where also the modules will be installed, at this point I don't know if we still have to determine "MODULES_PATH". "AMPATH" if available as a non RW directory will prevent the update of AM and the modules. They all will be managed by the package manager you are creating the package for. According to the above function, this would be the structure of a package:
of course, as suggested by @Samueru-sama , other options for "AMPATH" would be /usr/bin/AM, /usr/lib/AM, /usr/libexec/AM, or /var/lib/AM. Its up to you. Since this feature was asked by you two first, I'd like to have your opinion @fiftydinar and @vitaly-zdanevich Let me know. |
I think it should solve also #826 then |
@Samueru-sama should this be enough also to determine where the modules must be saved?
EDIT: just tested, nope, I must set again MODULES_PATH="$AMPATH/modules", like this
|
also, I noticed that if I don't set a valid RW AMPATH, any option will ask for root password, also in AppMan Mode so this should be the way to go
about replacing /usr/lib/am with something else, its up to you @fiftydinar and @vitaly-zdanevich |
Maybe I should allow usage of some functions as root (for example, updating the apps) instead of suggesting to use appman mode |
I agree with this hierarchy & code looks good Will test further in my test image how well it works when this gets merged |
...next version 8.1 will allow installation of apps ouside the $HOME directory, see ivan-hc/AM#894
just started tests on a VM of Debian Stable with the following structure
and the obstacle I had was this function
that prompts me this I had to remove the "elif" to run -f normally so now I need a suggestion for that function |
"$AMPATH" is already created for "modules", and AM may not exist without it, in "normal mode", same for AppMan
Just finished to test in VM the new behaviour, all works as expected, also AppMan Mode Some notes:
the function "_use_sync" is the function responsible of updating AM and modules, so the command Normally it does three things:
well, since a package for a distro would be shipped fith its own copies of "AM" and modules, according with the structure above... you don't need to use "_sync_modules" and "_sync_amcli"
that said, if it is OK for you, I can merge this to main and release it as AM 8.1 |
This is a demo video where I test various things... apart Chromium that does not run in sandbox, but AM works also in appman mode. Note that normal AM shows that can manage also AM among the installed apps shown with simplescreenrecorder-2024-08-29_04.23.37.mkv.mp4 |
Add files via upload
Add files via upload
Add files via upload
...same as "-i"/"install", but to run only installation scripts for AppImages
Time to merge. |