Crates.io & AUR packages

[adamperkowski]

Hey Titus, as linutil continues to grow, I think it’s important to make it more accessible to a wider audience. One way to do this is by creating and maintaining packages for different platforms.
I'd like to offer to create and maintain the linutil package on crates.io and the following packages on the AUR:

• linutil - latest release built from source
• linutil-git - main branch built from source
• linutil-bin - latest binary

This includes:
For crates.io, modifying Cargo.toml file to meet the requirements (I'd open a PR), publishing the package and maintaining it.
For AUR, creating different PKGBUILDs for the packages and maintaining them.
Additionally, monitoring user feedback and issues on both platforms to address any concerns.
Probably updating linutil's documentation and README too, but that's up to you to decide.

I have the knowledge and experience needed for this and it would be a pleasure for me to do it.
So, what do you say?

EDIT:
The only issue with packaging on crates.io is that users that already have a version installed and there's a new release, don't have a "simple" way to update. https://stackoverflow.com/questions/34484361/does-cargo-install-have-an-equivalent-update-command
So I'd say installing from crates.io is not recommended.

[adamperkowski]

We'd also need to think about the version names here because we have YYYY.MM.DD, 0.1.0, v0.1 and v1.0 on YouTube. It's not gonna go well this way.
It's recommended to use ISO 8601 formatting (without dots or dashes) in case of timestamp naming for PKGBUILDs
but since cargo requires sematic versioning, I'd recommend switching to semver. That's gonna be much easier.

This includes GitHub release tags (for linutil-bin) of course.

[lj3954]

Linutil-pre & linutil-pre-bin would also need to be packaged, since there are separate prerelease builds. These packages would have to be updated in the case of releases as well, due to the lack of separate branches.

I think it would be preferable, though, for Chris to have maintainership over these packages, and to include steps in the prerelease & release workflows so these packages can be kept up to date without any maintenance burden.

[adamperkowski]

Linutil-pre & linutil-pre-bin would also need to be packaged, since there are separate prerelease builds.

Is this really neccessary though? Especially with linutil-git.

I think it would be preferable, though, for Chris to have maintainership over these packages

I agree as to crates.io (there is an option for multiple people to have access to crates), but if there are also gonna be packages in other distro repositories, I think it's better to have separate maintainers. (Chris can always co-maintain)

and to include steps in the prerelease & release workflows so these packages can be kept up to date without any maintenance burden.

This can be done much easier with functions inside PKGBUILDs.

[ChrisTitusTech]

Love this idea and I approve

[adamperkowski]

Will start working on the packages tomorrow. (I might do some today)

[adamperkowski]

linutil, linutil-git & linutil-bin up on AUR

[lj3954]

linutil, linutil-git & linutil-bin up on AUR

Your dependencies are not correct.
Binary release should not depend on any GNU libraries; it's statically linked against musl.
Linutil does not link against libalpm whatsoever; that dependency should be removed from all 3 packages. Scripts only call the pacman binary, which is covered by the pacman dependency instead. Such distro specific system libraries will never be dependencies of linutil, since it would require major complication with countless feature flags.

[jeevithakannan2]

• Remove the all dependencies from linutil and linutil-bin.
• Remove libalpm.so and pacman dependency from linutil-git

[lj3954]

Wrong. Linutil still depends on git and pacman, and the linutil package builds from source (just a fixed release, rather than the latest from git) so build dependencies are still required.

libalpm should be removed as a dependency from all linutil packages, and glibc & gcc-libs should be removed from linutil-bin.

[adamperkowski]

@lj3954 You're right. Don't know what are libalpm and clibs doing there. Must've missed that.

[jeevithakannan2]

Linutil is not git cloning as per the PKGBUILD. It is just downloading the release tar and extracting it. So we don't need git as a dependency. Can I know why pacman is a dependency?

[adamperkowski]

Linutil is not git cloning as per the PKGBUILD. It is just downloading the release tar and extracting it. So we don't need git as a dependency. Can I know why pacman is a dependency?

It's for linutil's functionality. It depends on pacman for installing packages and git for various scripts.

[adamperkowski]

AUR packages updated to support ARM

[adamperkowski]

Made changes neccessary to publish in #549.

[adamperkowski]

Crates are up!
https://crates.io/crates/linutil_tui
https://crates.io/crates/linutil_core