m1guelpf / m1guelpf/auto-commit

Common installation expectations

Open
#11 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
1.2k
Forks
61
PR merge metrics
No merged PRs in 30d

Description

Hi! Thanks for this cool project.

I discovered, and installed this tool from the AUR, and after installation, I couldn't identify what files had been installed as a result.
Files installed via pacman, or from the AUR via a helper are typically discoverable by running pacman -Qql auto-commit, where you'd see the path of the new binary/lib/service/doc as a result of the installation, but that query returned nothing after installing auto-commit.

I looked at the PKGBUILD and saw that it was executing install.sh during the package() step. This works fine, but results in some unexpected behavior:

  • New files added to the system are not known to pacman, so the user cannot query them, nor can the files be removed during an uninstall
  • The install.sh script suggests placing the executable binary in ~/.bin, which is not a standard directory (though maybe common? I've always used a ~/bin, and haven't seen ~/.bin used before)
    installing them)
  • Running makepkg on the PKGBUILD file locally results in a failure, as it appears to contain some errors
  • Installing this from the AUR resulted in a pre-compiled binary being installed, which wasn't what I was expecting (though you could say that I should probably be reviewing every PKGBUILD before

I normally expect the AUR package name to inform me as to what will be executed:

  • <pkg-name>: I'll be building a tarball of the latest release
  • <pkg-name>-git: I'll be building from the HEAD of the main branch
  • <pkg-name>-bin: I'll be pulling a pre-built binary from the latest release
  • <pkg-name>-bin-git/<pkg-name>-nightly(-bin): I'll be pulling a pre-built binary from some build process that happens more frequently than tagged releases (pre-release/dev/nightly)

I'm not at all suggesting that any of those things are hard rules or anything, but rather I just wanted to open the conversation.
I created a draft PR that contains some possible configurations to see if you felt there was a particular one that you might favor, or all if you'd like. https://github.com/m1guelpf/auto-commit/pull/10
I didn't do any workflow modification since this was more of an exploratory effort.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the PKGBUILD and install.sh, then inspect the exploratory configurations in PR #10. Check how makepkg and the AUR installation handle files, binaries, and removal. Done means the project has an agreed, reproducible packaging approach with documented installation expectations.

Written by the indexing model from the issue text.

Assessment

Tech stack
arch-linux, rust
Domain
build-system, cli, release
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.