Plans

[simoniz0r]

This issue is a list of things that I plan on implementing/changing in spm:

• [x] Remove ssft.sh and create functions to replace it. Replace some text outputs in update argument with progress bars. Replace all completed messages with newly created message functions. Display info on install, uninstall, etc within these messages instead of as a separate message.

• [x] Use one large json file to list all packages and use csplit to split it into separate json files that are easy to manage. This should reduce update check time when changes have been made to spm's repo by quite a bit.

• [x] Add option at end of update argument to automatically start upgrades if they are available.

• [x] Create revert function that stores last version of package before upgrading to new one with options for how many packages should be stored, etc. This also requires a freeze function to prevent future updates until the user OKs them.

~~Create functions that source in special instructions for AppImages and tars containing things such as update info for packages that can't be checked for updates, pre/post install instructions, etc.~~

• [ ] Add support for building AppImages not provided upstream using deb2appimage

[silvernode]

Sounds good, hopefully you can get around to doing these. I use your program every day.

[simoniz0r]

I'm glad to hear that you use spm frequently :D

I've been throwing some ideas around lately for doing a complete rewrite. I'm probably going to make individual scripts for each package to manage installing/updating/removing them. This will make spm easier to work with and more reliable in the long run. It will also allow me to add more than just AppImages and precompiled tars. I would even be able to add stuff like themes, icons, etc.

[silvernode]

Awesome! I tried to get spm added to the void-packages repository though it didn't meet the standards apparently. Maybe a complete rewrite is what is necessary to clean things up. Let me know if there's anything I can help with as I know a rewrite is time consuming and easy to procrastinate.

My skills are ok but not great, just look at my profile for examples.

[simoniz0r]

Plans updated

[hub229ox]

the next logical step is to GUIfy spm using fltk_dialog_Appimage .

sth. bash.sh like:

#!/bin/bash 
./fltk-dialog_appi --title=' bashy  Packet Manager'  --yes-label=Liste   --width=600 --height=400    --radiolist=' accessimap-lecteur-der | ahgequip | ai-bot-workspace | aidos | aillio-ts | akiee | alduin | alphat | altair | amphetype2 | anavis | animationmaker | ansiweather | ao | aphelion_wallet | apla '   
#--dnd 

##   &
#./fltk-dialog_appi  --text=kate_tooltip  --indicator=kate      --text=rrr  --indicator=kwrite    
# in KDE , the tooltip is not working , limited utility !
 
##   --dnd   # drop an AppI to install  
## &  ./fltk-dialog_appi  --file    --native-qt   
#--question           
#--native-qt5                               
#--html=./appis # show list of AppImgs
##              --yes-label=install_AppI  --yes-label=oh_yes

# pidof fltk-dialog_appi 
# use pid to terminate old windows in update-loop 

[Revanee]

I love how easy it is to use, but I think it should integrate with something like appimage.github.io to maintain a solid catalog of available software. There isn't really a decent AppImage package manager right now and I think spm could become quite popular if it weren't for the lack of available software.

[simoniz0r]

I love how easy it is to use, but I think it should integrate with something like appimage.github.io to maintain a solid catalog of available software. There isn't really a decent AppImage package manager right now and I think spm could become quite popular if it weren't for the lack of available software.

That was the plan, however, I've found spm to be unreliable for updating certain github releases, and appimage.github.io does not at all provide links for things that aren't on github.

There's a few reasons why no good package manager exists for AppImages:

1. probonopd hates package managers (I wish I was joking here, but I'm not)
2. probonopd refuses to track versions for AppImages on appimage.github.io
3. probonopd refuses to track URLs for AppImages that are not on github
4. since probonopd refuses to track versions, many AppImages listed on appimage.github.io no longer exist

They do provide a json feed of all of the AppImages listed on the site, but without version tracking and URLs for AppImages not stored on github, the json feed is relatively useless.

Finding out how difficult probonopd is to work with for literally anything has all but killed my motivation for this project, unfortunately. I had planned on writing a script to parse their json feed into something usable, but I have little to no motivation to do anything related to AppImages anymore due to how difficult probonopd is to work with.

appimagedl does integrate with appimage.github.io, but I haven't touched it in quite some time. Maybe at some point in the future I'll find the motivation to work on spm again and switch it to using the json feed appimage.github.io provides, but that would mean spm would only provide AppImages stored on github, and I would still have no way to solve the problem of finding the latest AppImage when the releases page has multiple versions under one release.

[silvernode]

Looks like we will have to generate our own json file then. Unless that's already what happens in spm.

On Fri, Oct 11, 2019, 05:56 Syretia [email protected] wrote:

I love how easy it is to use, but I think it should integrate with something like appimage.github.io to maintain a solid catalog of available software. There isn't really a decent AppImage package manager right now and I think spm could become quite popular if it weren't for the lack of available software.

That was the plan, however, I've found spm to be unreliable for updating certain github releases, and appimage.github.io does not at all provide links for things that aren't on github.

There's a few reasons why no good package manager exists for AppImages:

1. probonopd hates package managers
2. probonopd refuses to track versions for AppImages on appimage.github.io
3. probonopd refuses to track URLs for AppImages that are not on github

They do provide a json feed https://appimage.github.io/feed.json of all of the AppImages listed on the site, but without version tracking and URLs for AppImages not stored on github, the json feed is relatively useless.

Finding out how difficult probonopd is to work with for literally anything has all but killed my motivation for this project, unfortunately.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/simoniz0r/spm/issues/8?email_source=notifications&email_token=AADCENDE54E74Y7LTPMDJQTQOBZV7A5CNFSM4DZLJXC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEA75APQ#issuecomment-541052990, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADCENGT244R7ZBR3VZTUY3QOBZV7ANCNFSM4DZLJXCQ .