3 added 247 characters in body
source | link

Packages can ship with arbitrary files that sit in the same directory as the PKGBUILD file. For your purposes, you can do just that. Within the PKGBUILD file's package() function, you can refer to those files as ${srcdir}/my-executable. The end result might look like this:

# snip!
source=(my-executable)
sha256sums=('foo')

package() {
  install -Dm755 "${srcdir}/my-executable" "${pkgdir}/usr/local/bin/my-executable"
}

You can now make a package with:

updpkgsums && mksrcinfo && makepkg

Note that this approach is only really appropriate for homebrew packages. Do not take this approach if uploading packages to the AUR. The files that ship alongside your PKGBUILD should change infrequently - certainly not with every release. And if your executable is a binary, you will be disallowed from uploading your package to the AUR. (Or it'll work, and someone will find it and ban you.)

For a concrete example, check out mkgmap. It installs a simple wrapper script to /usr/bin/mkgmap. Note that I'm using a few anachronisms, like executing cd "${srcdir}/${pkgname}-${pkgver}" at the head of package().

Once you've created a package, there are several tools available for getting those packages to all your hosts. One nice application-specific tool is pacserve. (Thanks to jasonwryan for the tip.)

Also, consider looking in to a tool like Ansible. If you want the package manager to know about these executables, making a package is great. But if you want to place files in user directories like ~/.local/bin/, configuration management systems may serve you better.

Packages can ship with arbitrary files that sit in the same directory as the PKGBUILD file. For your purposes, you can do just that. Within the PKGBUILD file's package() function, you can refer to those files as ${srcdir}/my-executable. The end result might look like this:

# snip!
source=(my-executable)
sha256sums=('foo')

package() {
  install -Dm755 "${srcdir}/my-executable" "${pkgdir}/usr/local/bin/my-executable"
}

You can now make a package with:

updpkgsums && mksrcinfo && makepkg

Note that this approach is only really appropriate for homebrew packages. Do not take this approach if uploading packages to the AUR. The files that ship alongside your PKGBUILD should change infrequently - certainly not with every release. And if your executable is a binary, you will be disallowed from uploading your package to the AUR. (Or it'll work, and someone will find it and ban you.)

For a concrete example, check out mkgmap. It installs a simple wrapper script to /usr/bin/mkgmap. Note that I'm using a few anachronisms, like executing cd "${srcdir}/${pkgname}-${pkgver}" at the head of package().

Also, consider looking in to a tool like Ansible. If you want the package manager to know about these executables, making a package is great. But if you want to place files in user directories like ~/.local/bin/, configuration management systems may serve you better.

Packages can ship with arbitrary files that sit in the same directory as the PKGBUILD file. For your purposes, you can do just that. Within the PKGBUILD file's package() function, you can refer to those files as ${srcdir}/my-executable. The end result might look like this:

# snip!
source=(my-executable)
sha256sums=('foo')

package() {
  install -Dm755 "${srcdir}/my-executable" "${pkgdir}/usr/local/bin/my-executable"
}

You can now make a package with:

updpkgsums && mksrcinfo && makepkg

Note that this approach is only really appropriate for homebrew packages. Do not take this approach if uploading packages to the AUR. The files that ship alongside your PKGBUILD should change infrequently - certainly not with every release. And if your executable is a binary, you will be disallowed from uploading your package to the AUR. (Or it'll work, and someone will find it and ban you.)

For a concrete example, check out mkgmap. It installs a simple wrapper script to /usr/bin/mkgmap. Note that I'm using a few anachronisms, like executing cd "${srcdir}/${pkgname}-${pkgver}" at the head of package().

Once you've created a package, there are several tools available for getting those packages to all your hosts. One nice application-specific tool is pacserve. (Thanks to jasonwryan for the tip.)

Also, consider looking in to a tool like Ansible. If you want the package manager to know about these executables, making a package is great. But if you want to place files in user directories like ~/.local/bin/, configuration management systems may serve you better.

2 Add syntax highlighting
source | link

Packages can ship with arbitrary files that sit in the same directory as the PKGBUILD file. For your purposes, you can do just that. Within the PKGBUILD file's package() function, you can refer to those files as ${srcdir}/my-executable. The end result might look like this:

# snip!
source=(my-executable)
sha256sums=('foo')

package() {
  install -Dm755 "${srcdir}/my-executable" "${pkgdir}/usr/local/bin/my-executable"
}
# snip!
source=(my-executable)
sha256sums=('foo')

package() {
  install -Dm755 "${srcdir}/my-executable" "${pkgdir}/usr/local/bin/my-executable"
}

You can now make a package with:

updpkgsums && mksrcinfo && makepkg

Note that this approach is only really appropriate for homebrew packages. Do not take this approach if uploading packages to the AUR. The files that ship alongside your PKGBUILD should change infrequently - certainly not with every release. And if your executable is a binary, you will be disallowed from uploading your package to the AUR. (Or it'll work, and someone will find it and ban you.)

For a concrete example, check out mkgmap. It installs a simple wrapper script to /usr/bin/mkgmap. Note that I'm using a few anachronisms, like executing cd "${srcdir}/${pkgname}-${pkgver}" at the head of package().

Also, consider looking in to a tool like Ansible. If you want the package manager to know about these executables, making a package is great. But if you want to place files in user directories like ~/.local/bin/, configuration management systems may serve you better.

Packages can ship with arbitrary files that sit in the same directory as the PKGBUILD file. For your purposes, you can do just that. Within the PKGBUILD file's package() function, you can refer to those files as ${srcdir}/my-executable. The end result might look like this:

# snip!
source=(my-executable)
sha256sums=('foo')

package() {
  install -Dm755 "${srcdir}/my-executable" "${pkgdir}/usr/local/bin/my-executable"
}

You can now make a package with:

updpkgsums && mksrcinfo && makepkg

Note that this approach is only really appropriate for homebrew packages. Do not take this approach if uploading packages to the AUR. The files that ship alongside your PKGBUILD should change infrequently - certainly not with every release. And if your executable is a binary, you will be disallowed from uploading your package to the AUR. (Or it'll work, and someone will find it and ban you.)

For a concrete example, check out mkgmap. It installs a simple wrapper script to /usr/bin/mkgmap. Note that I'm using a few anachronisms, like executing cd "${srcdir}/${pkgname}-${pkgver}" at the head of package().

Also, consider looking in to a tool like Ansible. If you want the package manager to know about these executables, making a package is great. But if you want to place files in user directories like ~/.local/bin/, configuration management systems may serve you better.

Packages can ship with arbitrary files that sit in the same directory as the PKGBUILD file. For your purposes, you can do just that. Within the PKGBUILD file's package() function, you can refer to those files as ${srcdir}/my-executable. The end result might look like this:

# snip!
source=(my-executable)
sha256sums=('foo')

package() {
  install -Dm755 "${srcdir}/my-executable" "${pkgdir}/usr/local/bin/my-executable"
}

You can now make a package with:

updpkgsums && mksrcinfo && makepkg

Note that this approach is only really appropriate for homebrew packages. Do not take this approach if uploading packages to the AUR. The files that ship alongside your PKGBUILD should change infrequently - certainly not with every release. And if your executable is a binary, you will be disallowed from uploading your package to the AUR. (Or it'll work, and someone will find it and ban you.)

For a concrete example, check out mkgmap. It installs a simple wrapper script to /usr/bin/mkgmap. Note that I'm using a few anachronisms, like executing cd "${srcdir}/${pkgname}-${pkgver}" at the head of package().

Also, consider looking in to a tool like Ansible. If you want the package manager to know about these executables, making a package is great. But if you want to place files in user directories like ~/.local/bin/, configuration management systems may serve you better.

1
source | link

Packages can ship with arbitrary files that sit in the same directory as the PKGBUILD file. For your purposes, you can do just that. Within the PKGBUILD file's package() function, you can refer to those files as ${srcdir}/my-executable. The end result might look like this:

# snip!
source=(my-executable)
sha256sums=('foo')

package() {
  install -Dm755 "${srcdir}/my-executable" "${pkgdir}/usr/local/bin/my-executable"
}

You can now make a package with:

updpkgsums && mksrcinfo && makepkg

Note that this approach is only really appropriate for homebrew packages. Do not take this approach if uploading packages to the AUR. The files that ship alongside your PKGBUILD should change infrequently - certainly not with every release. And if your executable is a binary, you will be disallowed from uploading your package to the AUR. (Or it'll work, and someone will find it and ban you.)

For a concrete example, check out mkgmap. It installs a simple wrapper script to /usr/bin/mkgmap. Note that I'm using a few anachronisms, like executing cd "${srcdir}/${pkgname}-${pkgver}" at the head of package().

Also, consider looking in to a tool like Ansible. If you want the package manager to know about these executables, making a package is great. But if you want to place files in user directories like ~/.local/bin/, configuration management systems may serve you better.