Autoexec in seperate repo?

[CarbonChauvinist]

Have you ever considered breaking out autoexec into a separate and dedicated repo? Would make it a lot easier for those wanting to package for AUR as a git package for instance.

[terminalforlife]

Oh yeah. I've thought about that for a lot of my programs, but it'd be a monumental pain in my ass, not to mention bring the commit count down to 0, and remove all of its history, at least from the perspective of the would-be new repository.

There may come a day when I just go ahead with it, but I'm not quite ready for that, yet. Lol

As for packing for the AUR, what else could I do to make it easier? It's already on the AUR, but it's a very old version, I think.

[CarbonChauvinist]

I'm sure, I just think the energy and enthusiasm behind autoexec specifically makes it worth the effort to break it out to its own repo -- not every one of your projects need to have that done though.

As for packaging in the aur, yes I see it's already been uploaded, but they are using a convoluted (imo) method of extracting from an older deb packaged version from your now archived DEB-Packages repo.

Since this is a straight forward install (just three files, man page, completion source and bash script) it is just a simple install. Right now, I've just created a personal PKGBUILD for my own use. But I'm also lazy and don't want to faff about with updating the PKGBUILD every time you make an update to the code for autoexec.

The thing is, this can be automated with a vcs PKGBUILD. But it will only work (TMK) with it in a dedicated repo. Then any time you make a change to the repo, without any interaction, the package will be rebuilt.

But, this may all be a moot point if you don't anticipate much future changes to the code. Either way thanks for creating and sharing this project. There's a reason why you get a ton of questions about it, it really does stand out and is super interesting and useful.

[terminalforlife]

Thank you. :) I use it all the time. I think most of the heavy changes have already been done, thankfully. Older versions weren't stable, and had ill-thought-out features, but I think it's in a really good state, now.

I don't know anything about building packages for Arch, only Debian.

[CarbonChauvinist]

Also you can break out to separate repo and keep your commit history.

[terminalforlife]

Wow! I had no idea you could filter out commits like that. Very cool.

[CarbonChauvinist]

Closing out this ticket -- As I wasn't too keen on the existing package in the AUR for this project, I went ahead and cobbled together my own PKGBUILD for this that I'll just manually update if/when needed.

pkgname=autoexec-my
_pkgname=${pkgname%-my}
pkgver=1
pkgrel=0
pkgdesc="Development tool for automatic execution of files"
arch=("any")
url="https://github.com/terminalforlife/Extra"
_url="https://raw.githubusercontent.com/terminalforlife/Extra/master"
license=("custom:GPLv3")
depends=("bash")
source=("$pkgname-$pkgver-completions::$_url/source/$_pkgname/completions"
  "$pkgname-$pkgver::$_url/source/$_pkgname/$_pkgname"
  "$pkgname-$pkgver.1.gz::$_url/$_pkgname.1.gz"
  "$pkgname-$pkgver-LICENSE::$_url/LICENSE")
noextract=("$pkgname-$pkgver.1.gz")
sha256sums=('bf831972e4b077635b9f3ddcf7678265f75713f33894f09f6525b33abf194694'
            '1e1d47586512405c10ef3f2ed41f18bf2528b6dde49d2b05c0f664fcc746ef65'
            'b9b5a466f737e00c20b5e1ac56c3f2f8e596ad6348a5eac4704c17d68df6e4a5'
            '589ed823e9a84c56feb95ac58e7cf384626b9cbf4fda2a907bc36e103de1bad2')

package() {
  install -Dm755 "$srcdir/$pkgname-$pkgver" "$pkgdir/usr/bin/$_pkgname"
  install -Dm644 "$srcdir/$pkgname-$pkgver.1.gz" "$pkgdir/usr/share/man/man1/$_pkgname.1.gz"
  install -Dm644 "$srcdir/$pkgname-$pkgver-completions" "$pkgdir/usr/share/bash-completion/completions/$_pkgname"
  install -Dm644 "$srcdir/$pkgname-$pkgver-LICENSE" "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
}

Thanks again for creating and sharing this.

[terminalforlife]

Noice! Can you update the short description? It's been: "Development tool for automatic execution of files" for a while, because "scripts" was misleading. Also, you've missed some dependencies: it also needs the Debian packages coreutils, file, and ncurses-bin, so whatever they are in Arch are needed.

[CarbonChauvinist]

Noice! Can you update the short description? It's been: "Development tool for automatic execution of files" for a while, because "scripts" was misleading.

Of course, this is mainly just a personal build I use on my own box, but I've updated my post with the corrected description.

Also, you've missed some dependencies: it also needs the Debian packages coreutils, file, and ncurses-bin, so whatever they are in Arch are needed.

So Arch handles those a little differently. coreutils and file are already required by/part of the base package group that is installed on every system so they don't need to be explicitly required.

# list dependencies of the base package group and grep for coreutils and file
$ pactree --depth 1 --linear base | grep -Ei 'coreutils|file$'
coreutils
file

Likewise ncurses is also a dependency of the bash package so is also covered by the single explicit requirement of bash in the PKGBUILD

$ pactree --depth 1 --linear bash | grep -i ncurses
ncurses

As you can see, and I'm sure you'll appreciate, the beauty of arch packaging is that they are essentially just shell scripts!

[terminalforlife]

Dang, that does some pretty noice. After building a ton of Debian packages for ages, I can totally see why packaging for Arch would be so much easier. Thanks for updating and the info. :)