[Feature Request] upgrade (all), search, list installed?

[pwFoo]

Hi @aerys ,
I found your awesome package manager and really like it! It works with a ~2MB small binary and supports multiple repositories.
What's about features like

• upgrade (all) package(s)
• search for packages
• list installed packages
• package info (version, description, ...)

Not all features are really needed, but would be interesting if planned or possible with a still small binary?

[JMLX42]

search for packages

We're considering it.

package info (version, description, ...)

We keep track of package versions by adding a VERSION file in the content of each package.
So we can easily know what is the current version of an "installed" package. But it is not a GPM requirement.

We're also thinking about adding support for a CHANGELOG file that would be committed on the git repository. This file will be used to show the changelog of a specific version of the package.
The file system would look like this:

/
     my-package/
          my-package.tar.gz
          CHANGELOG
    my-other-package/
          my-other-package.tar.gz
          CHANGELOG
...

with a still small binary?

I'm pretty sure adding the features above will have only a small impact on the final binary size.

upgrade (all) package(s)
list installed packages

GPM does not keep track of installed packages. And we have no "package metadata" file (like NodeJS' package.json for example). And I'm afraid we can't achieve this kind of feature without this kind of additions.

[pwFoo]

Hi @promethe42 ,
my idea as workaround would a wrapper script (bash for now...) which add installed packages to a file like alpine /etc/apk/world.

But uninstall / update seems not supported? Update should replace the old package? Would it possible to do that with a --force or --reinstall or some other option? Just remove the old package and install the new one (would be nice to make sure old content is removed, not just overwrite the old contents with new files).

But maybe that would be to complex?

[JMLX42]

my idea as workaround would a wrapper script (bash for now...) which add installed packages to a file like alpine /etc/apk/world.

That's a good idea. Do you know what's the content/format of /etc/apk/world?
Do you have examples?

GPM already relies on the ~/.gpm folder to store metadata/cache. So it could remember which package was installed. A very cool trick would be to store the package installation history as a local git repository. So it would be possible to backup/restore/revert the package install using the git history.

[pwFoo]

World file ist just a Line based list of installed packages like

busybox
ca-certificates
[...]

With the list of package names IT should be easy to implement an update / upgrade action for installed packages.

Local git repo is interesting too... But I don't know if that would fit my setup. I need to take a closer look.

[JMLX42]

I guess the "git repo" would likely just be that single file but with got-powered revisions.

So for example you could tag your current packages and restore them using get checkout.

[pwFoo]

you mean ./gpm/world file as local git repo with tags? I just used simple git clone / push before ...

Would that exampe do what you are thinking of?

1. install a package
2. git add world
3. git commit -m "os revision 1.0.1"
4. git tag os/1.0.1

Revert to would be? git checkout <TAG>?

But how to revert the installed files to the earlier revision...? Files could be installed to system root dependent on file structure of gpm package. Or is there a gpm uninstall action which takes care about remove all files of package?

[JMLX42]

You would not do the git commands yourself: gpm will do it transparently for you. Something like:

# install my-package1 and tag/commit the corresponding change
$ gpm install my-package1 --commit "first install"
# install my-package2 and tag/commit the corresponding change
$ gpm install my-package2 --commit "another install"
# revert to the "first install" package list, so my-package2 will be uninstalled
$ gpm checkout "first install"

The --commit option would be optionnal.

[pwFoo]

Good Idea! --commit could bei generated something like <package>/<version>?

So it should be possible new features update, revert / downgrade and uninstall?

But disk space may bei increase dependent on archive / binary size?

So clear history (delete history / .git directory?) should be an option?

[JMLX42]

Good Idea! --commit could bei generated something like /?

I was thinking it would be an actual user-provided commit message.

So it should be possible new features update, revert / downgrade and uninstall?

That the point: gpm would install/uninstall packages based on the diff generated by the git operations on that record file.

But disk space may bei increase dependent on archive / binary size?

As of today, package archives are never stored locally. So:

• the size of that local git repository would be very very small: it would store only the history of a file equivalent to /etc/apk/world
• gpm would still require an internet connection to download them. But just like we have a cache for the GPM-compliant git repositories in .gpm/cache, we could have a cache for the package archives.

Each package archive is already hashed using SHA256 in order to resolve/match/check GIT LFS links. So we could use that hash to index/store package archives in cache.

So clear history (delete history / .git directory?) should be an option?

I guess so. In the end, it would be:

• a git repository to track package install changes
• a cache folder for package archives (with a fallback on re-downloading the package archive)

[pwFoo]

Commit message could bei optional User Provider or generated by package name + version (+ date / time)? Would bei easy to search / find?

Local package (contents / tar.gz) cache would bei nice for some testing / debugging Tasks, but most cases should be Install and delete cached File I think?

How so you revert / uninstall the extracted files? List files / directories from archive and deleted all those files and directories (If empty)? Or is there a better way to do that?

The world file just contains the package name in alpine distribution.
Do we need additional information like version / hash, date / time, something else to get more possibilities?
Or do we need to add all the package files / directories to world file to have the needed diff?

[JMLX42]

Do we need additional information like version / hash, date / time, something else to get more possibilities?

All of that would be provided by the git history of the "world" file.

Local package (contents / tar.gz) cache would bei nice for some testing / debugging Tasks, but most cases should be Install and delete cached File I think?

AFAIK we can list the files/content of the archive .tar.gz without extracting it.

[pwFoo]

Yes, list should be tar tzf <archive>.

[pwFoo]

With package list (world file) and File list (of all installed packages) and currently installed versions some cool features could bei possible.

• check file conflicts of packages (if same file is provided by more than one package, maybe notify during un-/Install, delete or update a package)
• list installed packages
• list files of a package
• update / uninstall by delete listed files of package (and install new package then)
• check If updates available (update cache, check version against installed version)
• Install / update history / order (by timestamp, commit date)

I think all the features should be possible without to much code? Or with a "extension" script?

Would that possible with the local git repository for world file? I don't know how to get the needed information from git repo.

[pwFoo]

@promethe42
I started to build a custom fun linux based on busybox, rustysd, crun and gpm. Build is based on linuxkit.
https://github.com/dengleros/dosctl/blob/master/README.md

[JMLX42]

check file conflicts of packages (if same file is provided by more than one package, maybe notify during un-/Install, delete or update a package)
list installed packages
list files of a package
update / uninstall by delete listed files of package (and install new package then)
check If updates available (update cache, check version against installed version)
Install / update history / order (by timestamp, commit date)

IMHO most (all?) of this is doable without adding new crates. So I guess it won't add much weight to the static binary.

Please keep this issue about upgrade/search/list only. Please open a new issue if you have other issue requests.