Package Details: aur-box 19-1

Git Clone URL: https://aur.archlinux.org/aur-box.git (read-only)
Package Base: aur-box
Description: Publishes software instantly to Arch Linuxes
Upstream URL: https://gitlab.com/es20490446e/aur-box
Keywords: aur git makepkg pkgbuild publisher
Licenses: GPL3
Conflicts: aur-box
Provides: aur-box
Submitter: es20490446e
Maintainer: None
Last Packager: es20490446e
Votes: 0
Popularity: 0.000000
First Submitted: 2019-11-02 20:54
Last Updated: 2019-11-15 14:04

Dependencies (2)

Required by (0)

Sources (1)

Latest Comments

1 2 Next › Last »

es20490446e commented on 2019-11-15 14:42

That is something I have been thinking lately. Simply put for most of my software I decided that every single commit is a new stable release itself.

This is because releasing later than that won't make much sense since:

  • There's nothing to compile, and the software is minimal. So frequent upgrades won't disrupt the end user.

  • The software has a limited set of capabilities. So once it reaches maturity it's predictable it to have very few updates.

  • Each commit is thoroughly tested to be bug free.

  • Releasing faster to the end user minimizes the impact of any potential bug.

Then if to suffix or not is not very clear, as then the package fits both situations.

Nevertheless AUR helpers treats suffixed packages different than non suffixed ones. For example for non suffixed ones they will check new versions using the AUR Web, and for suffixed ones using pkgver(). The later method taking way longer when you have a bunch of suffixed packages installed.

It could be that if the package is suffixed it is never updated by the AUR helper, except if you mark the option to update development packages. This is the case of Pamac.

The problem here is that any suffixed package is assumed to be a development package, when in this case it's also stable. So I have yet to investigate the details, I was leaving it for when I got dependent decisions decided.

coderobe commented on 2019-11-15 14:15

Another issue is that this package is building git master HEAD, if it builds from master HEAD, pkgname should have the -git suffix. unprefixed pkgnames are supposed to build a stable release, or a tagged commit when no stable release is available

es20490446e commented on 2019-11-15 14:06

Fixed.

And about the Makefile I thought it would just be easier to reference this package, as packaging is only four line of code.

diabonas commented on 2019-11-15 10:45

You can install multiple files by using

install -Dm755 "${srcdir}"/"${pkgname}"/assets/box/* -t "${pkgdir}/usr/lib/box"
install -Dm644 "${srcdir}/${pkgname}/assets/box.1" -t "${pkgdir}/usr/share/man/man1"

Note that I changed /usr/share to /usr/lib because that is the proper location according to the Filesystem Hierarchy Standard.

Even better would be writing a simple Makefile that installs all the files to the proper location and put it into your GitLab repository. This would also make it easier for other people to install your application directly from the repository without relying on the AUR package.

es20490446e commented on 2019-11-15 09:13

Also when the package is large is way more interesting moving the files instead of copying them, as one is instant and the other takes a while.

es20490446e commented on 2019-11-15 09:12

Ah, you mean me setting permissions using chmod instead of install.

The problem with install is that it doesn't support folders directly, and I want to copy all the files within a folder no matter if new ones appear upstream or not.

Coding that with install will be longer, less clear and more error prone I think.

es20490446e commented on 2019-11-15 07:24

Still I haven't understood what are the find and chmod/chown hacks. Could you explain?

es20490446e commented on 2019-11-15 07:22

Review now.

es20490446e commented on 2019-11-14 23:22

This will be fixed within a week.

coderobe commented on 2019-11-14 21:42

it should also depend on commits-count, not commits-count-git, unless it explicitly requires unreleased features in commits-count