PackageKit provides support for many Linux PMs. Add a single adapter for PackageKit, and most all disastrous are covered.

Credits: u/DrReadIt

Issue

Trying to use the --using or the --pm options to change the package manager have to effect if the setting is overridden by a config.toml.
I'm on Windows 10.

My config file (at ~\.config\pacaptr\pacaptr.toml looks like this:

# This enforces the use of `install` instead of
# `reinstall` in `pacaptr -S`
needed = true

# Explicitly set the default package manager
default_pm = "winget"

Expected Outcome

Using the --using or the --pm options changes the package manager (unless I'm using them wrong):

PowerShell 7.4.1
PS user@hostname:C:\Users\user> pacaptr -V
pacaptr v0.20.1
PS user@hostname:C:\Users\user> sudo pacaptr --using choco -Ss fastfetch
  Running `choco search fastfetch`
Chocolatey v2.2.2
0 packages found.
PS user@hostname:C:\Users\user> pacaptr --using scoop -Ss fastfetch
  Running `scoop search fastfetch`
Results from local buckets...

Name      Version Source Binaries
----      ------- ------ --------
fastfetch 2.7.0   main

PS user@hostname:C:\Users\user> pacaptr -Ss fastfetch
  Running `winget search --accept-source-agreements fastfetch`
No package found matching input criteria.
    Error Subprocess exited with code -1978335212

Actual Outcome

When I try to use Chocolatey or Scoop instead, it still runs Winget (P.S. Scoop has a package named fastfetch, while Chocolatey and Winget don't):

PowerShell 7.4.1
PS user@hostname:C:\Users\user> pacaptr -V
pacaptr v0.20.1
PS user@hostname:C:\Users\user> sudo pacaptr --using choco -Ss fastfetch
  Running `winget search --accept-source-agreements fastfetch`
No package found matching input criteria.
    Error Subprocess exited with code -1978335212
PS user@hostname:C:\Users\user> pacaptr --using scoop -Ss fastfetch
  Running `winget search --accept-source-agreements fastfetch`
No package found matching input criteria.
    Error Subprocess exited with code -1978335212
PS user@hostname:C:\Users\user> pacaptr -Ss fastfetch
  Running `winget search --accept-source-agreements fastfetch`
No package found matching input criteria.
    Error Subprocess exited with code -1978335212

Automatic sudo DOES work, but the lack of prompt message asking for password will definitely cause confusion.

On Alpine, the prebuilt amd64 asset:

$ ldd /usr/local/bin/pacaptr
        /lib64/ld-linux-x86-64.so.2 (0x7f695f48c000)
        libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f695f48c000)
        librt.so.1 => /lib64/ld-linux-x86-64.so.2 (0x7f695f48c000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f695f48c000)
Error loading shared library libgcc_s.so.1: No such file or directory (needed by /usr/local/bin/pacaptr)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f695f48c000)
Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /usr/local/bin/pacaptr)
Error relocating /usr/local/bin/pacaptr: _Unwind_Resume: symbol not found
Error relocating /usr/local/bin/pacaptr: _Unwind_GetRegionStart: symbol not found
Error relocating /usr/local/bin/pacaptr: _Unwind_SetGR: symbol not found
Error relocating /usr/local/bin/pacaptr: _Unwind_GetDataRelBase: symbol not found
Error relocating /usr/local/bin/pacaptr: _Unwind_GetLanguageSpecificData: symbol not found
Error relocating /usr/local/bin/pacaptr: _Unwind_RaiseException: symbol not found
Error relocating /usr/local/bin/pacaptr: _Unwind_FindEnclosingFunction: symbol not found
Error relocating /usr/local/bin/pacaptr: _Unwind_GetIP: symbol not found
Error relocating /usr/local/bin/pacaptr: _Unwind_Backtrace: symbol not found
Error relocating /usr/local/bin/pacaptr: _Unwind_GetIPInfo: symbol not found
Error relocating /usr/local/bin/pacaptr: _Unwind_GetTextRelBase: symbol not found
Error relocating /usr/local/bin/pacaptr: _Unwind_SetIP: symbol not found

I installed this with scoop, and set the alias "pacman" for "pacaptr". When I run "pacman -Syu" which should run "scoop update" it instead runs "powershell scoop update". This gives me an Execution Policy error and says that the file "C:\Users<user>\scoop\shims\scoop.ps1" is not digitally signed. My Execution Policy is set to "Bypass" so this error should never happen, right? Can you please help me fix this, because this looks really cool and I would love to try it out!

[Hello. Most of us are using the scoop package manager. And as a person who came from using Arch most of the time I would love to have that syntax while using scoop. Thanking in advance

Link to scoop: HERE

Yes, I know now this is a rather small and immature project, but I really want it to be available on more package managers!

• cargo
• homebrew
• linuxbrew
• chocolatey
• scoop
• apt
• dnf

... and maybe some more linux repos?

Up till now, the common operations across different package managers are mapped directly to Pacman commands, which is a good solution in the very beginning, but might constraint the scope of this project.
We wish to extract the syntax layer from those operations into a library, so that on day we might be able use a different front-end (eg. an apt-like one).

pacaptr currently publishes pre-built artifacts with each release, but cargo binstall isn't aware of these artifacts, making cargo binstall pacaptr fail. See https://github.com/cargo-bins/cargo-binstall/blob/main/SUPPORT.md.

You can implement support via [package.metadata.binstall] keys in the crate manifest or via changing the artifact file name scheme to something cargo binstall will auto-detect. To see everything currently tried, try cargo binstall --log-level debug pacaptr. Specifying artifacts in the crate manifest should be preferred, as auto-detection requires querying the GitHub API about each tested artifact filename.

-Sy with keywords leads to calling apt update with keywords, which is invalid syntax.

Example:

> pacaptr -Sy gh
  Running `sudo -S apt update gh`
E: The update command takes no arguments
    Error Subprocess exited with code 100

The pacapt docs give a table of which options are supported for which package managers, which gives the newcomers a clear view of what the project is capable of. We should consider doing something similar as well.

Credits: u/I_Feel_It_Too

I using pacaptr -Si xxx to search remote package information.
Sometimes the package doesn't exist, when using dnf info xxx will return an error level of non zero, but pacaptr -Si xxx always return 0.
I want to detect an errorlevel if there is an error like Error: No matching Packages to list.
Can this program return an error level of 0 if successful and non zero if a problem is encountered?
Thanks

cc #5

pacaptr has been using hand-written GitHub Actions workflows for publishing since the very beginning.

However, in the long run, I would like to reduce the mental overhead of maintaining pacaptr by delegating the publishing workflow to the wonderful GoReleaser project.

I have been getting more familiar with GoReleaser by trying it on my other projects like Claveilleur, ting and Ouverture. When the time comes, I'll migrate pacaptr to GoReleaser.

At the same time, I would like to express my gratitude to all the collaborators working on package distribution, notably:

• @lynzrand for working on the original choco workflow;
• @amiarobot for adding debian packaging support;
• @meltinglava and @ptanmay143 for distributing pacaptr on scoop.

There’s a lot of random flags in package managers you have to set in docker to say please don’t cache this package which is important in docker to keep image sizes small.

Would be great to abstract this away behind a -no_cache flag or similar...

... in the future I could possibly make sudo -S replaceable with something else via the config (env var + cli args + config file).

This might include:

• gsudo on Windows: should work fine since the interactivity is implemented via a pop-up window.
• doas on *nix: might require working around the lack of sudo -S, see Duncaen/OpenDoas#21 (comment).
• run0: https://news.itsfoss.com/systemd-run0

Originally posted by @rami3l in #2 (comment)

The current program works fine with macOS/homerbrew, but mostly because brew is a root-less package manager. When working with Debian/apt, some big actions require sudo (eg. -S) while others don't (eg. -Si).

The problem is, should we implement auto invocation of sudo in pacaptr, or should we let the users themselves to decide?

If we accept the auto invocation, then we are deviating from the original behavior of pacapt, and this might complicate the support of different package managers. So in this case, we have to carefully consider how to implement this feature.

If not, there must be a way of installing pacaptr (other than using Linuxbrew and cargo install) so that it can be used through sudo (gsudo in Windows is not the case here). But then there comes another problem: the upcoming pacaptr.toml support means that the configuration is user-dependent.

I personally don't use homebrew, but I use MacPorts. I do miss pacman's syntax though, so would it be possible to add MacPorts as well?

Now that the overall structure of the project is rather stable, it's time to explain something about this project's structure so that a contributor can load it more efficiently in his/her mind cache.

This should be relatively easy if clap_complete can be leveraged.

One thing that made this project what it is today was homebrew's bad support for automatic cask detection.
Fortunately, homebrew has realized this problem and some brew cask commands have been deprecated.
However, this migration is not completed yet, and opting for the new syntax right now might break some common abstractions, so let's track the current status before we make the move:

Those brew commands with a tick can be used with --cask to force the detection result to be a cask. This coincides with our design decision in pacaptr (Nice!). So the --cask flag can be completely removed one day in clap.rs config.

• brew info
• brew install
• brew list (default is to list all when using tty, use --formula and --cask to show the respective half only)
• brew fetch
• brew reinstall
• brew uninstall
• brew upgrade

hello,
I just found out about this tool and tried it on my Mac m1
the brew install doesn't install a arm64 version and is not usable because it will try to run brew in rosetta2
is it possible to add a arm64 version?
I was able to compile it from git source, but it would be easier to do it with brew

Some want pacaptr to support scoop.
But sadly, I personally don't use this package manager, and thus I might end up with a wrong rosetta table.
Any help will be greatly appreciated!

As requested by @itsaleph:

#142 (comment)

I'd personally like to see support for Termux's pkg PM, which is essentially a wrapper around apt.

#142 (comment)

• apt list lists all packages available unless --installed was passed. pkg instead of the list command have two separate list-all (acts like apt list) and list-installed (self-describing).
• apt has both --help flag and help command, whereas pkg only has command. Additionally, pkg doesn't have man pages.
• pkg doesn't have the autoremove command (only autoclean).
• pkg doesn't have the full-upgrade command. pkg upgrade instead always asks user what to do in case of a conflict (i suspect this behaviour is the same as apt upgrade, but not sure since i never used it).
• pkg doesn't have satisfy and edit-sources commands.
• pkg has several command shortcuts like pkg in instead of pkg install and pkg rm instead of pkg remove.

Termux Wiki article on package management in Termux, including what is pkg and why it is (highly) recommended over apt.

If i understand correctly, the only thing missing from pkg support is that it should be preferred over apt by pacaptr if running inside Termux ($HOME or $PREFIX start with /data/data/com.termux/ or one of the following variables are defined: TERMUX_VERSION, TERMUX_IS_DEBUGGABLE_BUILD, TERMUX_MAIN_PACKAGE_FORMAT, TERMUX_API_VERSION, TERMUX_APK_RELEASE, TERMUX_APP_PID).

Currently, we build and test pacaptr in a single pass for each environment, however, the building process is pretty much repetitive.

In order to improve CI test efficiency, it might be better to first build all the test builds, and then run them on each test environment.

The BASH version had it, and I would like for the Rust version to support Portage as well.

hello,
i wonder if there is support for the official windows package manager
https://docs.microsoft.com/en-us/windows/package-manager/winget/
i prefer it over scoop and choco

As a follow-up of #652 and #653 (comment), if we add --disable-strategies compile when running cargo binstall pacaptr on Windows, we'll encounter the following error:

Failed to extract zipfile: feature not supported: 'stream reading entries with data descriptors (planned to be reintroduced)'

However, the metadata addition in #653 seems correct.
Thus, this is purely an upstream issue which requires no further changes from our side.

This issue should not be closed until:

• At least one of the following issues is closed:
  • cargo-bins/cargo-binstall#1080
  • Majored/rs-async-zip#94
• A PR is merged to revert 500d9cc.

Firstly, very cool project, thanks so much for OS-ing it.

Would love to contribute, tho I am completely unfamiliar with Rust for now, but it does seem like every OSS CLI tool is either rust or go, so might as well learn at some point.

My request:

I'm going to be vague about terminology like "query/installation operations", as I eagerly await #32 and don't want to jinx that decoupling from pacman too soon 😉

1. Operations that query packages could (per invocation opt-in, or globally configurable as default etc) "merge" the results of the enabled pms.
   2. Realistically, or UX-wise, it would really likely be the equivalent of returning x-many tables/lists of packages, with _x_ == num of pms
2. And similarly, ops that install packages would search over the various pms
   1. With a decent likelihood of overlap, we have diff options for resolution:
      1. Bork, and echo "so and so conflicts, pls specify amongst these:..."
      2. Auto proceed to installing via the already-user-or-per-os-configured-default pm
         3. if not otherwise opted-out perhaps via new flag
         4. maybe consider new config options for just this priority/resolution situation if ppl want it?
      3. Offer a readline-y/fzf-y/gum-y prompt to select amongst whichever ones were found
3. Again similarly, same for upgrading and uninstalling
   7. Tho of course, instead of querying the "remote store/repos" and then merging etc, we'd want to query only the locally installed stuff

I don't think this will really be a big value-add for linux, nor likely mac, as my experiences on both reveal few experiences with packages not being the os-default pm but being available on alternatives - eg, I've had like 2 occasions where port had something brew didn't.

But on Windows, I juggle so constantly between searching and then installing amongst scoop, choco, winget, that I wrote a pretty shitty/hacky powershell script to kinda do my suggestion above, converting/parsing the returns of each pm into PSCustomObjects and using gum to filter/install/confirm etc.

But I'd have to do some more heavy lifting to have that work nicely on mac and linux, which I've started using pwsh on, and also for supporting operations like uninstalling.

Not opposed to doing that, but I think this project already has significant progress made that might obviate doing that in my own hacky way.

Anyways, thanks again!

I got this after I run it:

bash-3.2$ pacaptr -h
Killed: 9

I installed pacaptr from Homebrew and the version of pacaptr is v0.8.0.

What's supported so far:

• Linux/linuxbrew
• Debian/apt
• RedHat/dnf
• Gentoo/emerge
• SUSE/zypper
• Alpine/apk
• Void/xbps (handled in #330)
• Linux/pkcon (#pacapt/226, handled in #538)

What isn't yet supported in pacaptr, but supported in pacapt:

• Exherbo/cave
• Clear/swupd
• SliTaz/tazpkg

I think it would be nice if you could add a -U option for scoop. Of course it would be a wrapper for scoop update.

Hello, and thanks!

I expect this is already planned, but I didn't see a tracking issue, just the current compatibility table confirming that installed packages can't yet be searched (qs in the table), using apt.