Hi Khorne, Thanks for your review.

More importantly it seems to me that you switched url and source around. The source array is used to define where to find (and potentially download) the sources. The url array is just a general hint, for example to an upstream project page.

I understand. The point here is that there are no source files to download and configure/make/makeinstall. Hence, I pointed the URL straight to the package file itself: https://www.loomsday.co.nz/repos/arch/disklow-1.2-2-any.pkg.tar.xz Is there an "official" place where I can upload the package itself? Or will I have to split it into PKGBUILD and source in order to play by the Arch rules? Happy to set up a local repository on my own rack server in a few weeks, though. Regards, Holger

On September 2, 2019 4:47:08 PM GMT+02:00, Eli Schwartz via aur-general <aur-general@archlinux.org> wrote:

On 9/2/19 6:50 AM, Khorne via aur-general wrote:

...

More importantly it seems to me that you switched url and source around. The source array is used to define where to find (and potentially download) the sources. The url array is just a general hint, for example to an upstream project page.

As it stands, the pkgbuild assumes the sources to be in cwd as a file. If that's intentional, carry on.

The url points to a valid prebuilt *.pkg.tar.xz, so that's not really a "source" either.

Granted, it turns out that's the case here. I didn't check the contents of the tarball but suspected as much.

Hi Daniel, Thanks for your review.

You'll need to install the PerlArtistic license.

What exactly do you mean by "install the license"? Put a copy of it into the package?

This may be a small tool, but you're not really supposed to host the source code in the AUR. It should be hosted elsewhere and downloaded.

The payload code is one Perl script with 1400+ lines. For brevity's sake I am trying to keep it in one package, but if the community rules dictate to split it into PKGBUILD & source, then so be it.

MD5 is old (and, some would argue, busted). Prefer SHA1, or better, SHA256.

I wrote a little build script in order to wrap everything into the package itself. The script uses makepkg -g >> PKGBUILD which produces the md5sums array. How do I get it to use something else than md5sum? Simply roll my own by using sha256sum? Regards, Holger

On 9/2/19 7:31 AM, Holger Jahn wrote:

Hi Daniel,

Thanks for your review.

...

You'll need to install the PerlArtistic license.

What exactly do you mean by "install the license"? Put a copy of it into the package?

core/licenses provides /usr/share/licenses/common/PerlArtistic/license.txt If you were actually in need of installing the license, then you would do so in accordance with https://wiki.archlinux.org/index.php/PKGBUILD#license

...

This may be a small tool, but you're not really supposed to host the source code in the AUR. It should be hosted elsewhere and downloaded.

The payload code is one Perl script with 1400+ lines.

For brevity's sake I am trying to keep it in one package, but if the community rules dictate to split it into PKGBUILD & source, then so be it.

The AUR graciously provides hosting for build recipes (PKGBUILD) and additional files needed for packaging (desktop files, those tiny shellscript wrappers which the java ecosystem is accursed with, kernel .config files, systemd units if upstream doesn't provide them, etc). The AUR does not provide source code hosting, on the grounds that other places like Github, Gitlab, git.sr.ht, amd so on are doing it better. Moreover, source code hosting is a resource burden on the provider, which in our case we do not have either a business or community rationale for accepting. (Again: we provide hosting for build recipes, because build recipes are something specific to Arch). We actually have a rudimentary enforcement method in the form of an upload validation script that will reject packages containing files which are "too big" and therefore seem like they cross the line from packaging files to source code. ... More generally, why would you upload your project in a way that is targeted exclusively for Arch users? What if users of a different distro wanted to use your software? And, regardless of where you host it, why would you upload it as a tarball checked into git? git already has excellent deduplication algorithms and the ability to diff versions of a file, but it is geared to text and is kind of terrible at handling often-changing binary files like a gzipped tarball. Over time, a repo containing tarballs will balloon in size.

...

MD5 is old (and, some would argue, busted). Prefer SHA1, or better, SHA256.

I wrote a little build script in order to wrap everything into the package itself. The script uses

makepkg -g >> PKGBUILD

which produces the md5sums array. How do I get it to use something else than md5sum? Simply roll my own by using sha256sum?

makepkg -g will generate new checksums for a PKGBUILD, using all the current checksum algorithms listed in the PKGBUILD, or, if there are none, using the INTEGRITY_CHECK setting in makepkg.conf The INTEGRITY_CHECK defaults to md5. ... Aside: using makepkg -g >> PKGBUILD will lead to repeatedly appending checksum lines, which you will need to edit in order to remove old versions. The updpkgsums script from pacman-contrib will use makepkg -g in order to update checksums in-place. -- Eli Schwartz Bug Wrangler and Trusted User

On Tue, Sep 03, 2019 at 10:52:36 +1200, Holger Jahn wrote:

...

The AUR does not provide source code hosting, on the grounds that other places like Github, Gitlab, git.sr.ht, amd so on are doing it better. Moreover, source code hosting is a resource burden on the provider, which in our case we do not have either a business or community rationale for accepting. (Again: we provide hosting for build recipes because build recipes are something specific to Arch).

Makes sense, and I would not have done it "my way" if it weren't for the fact that my source code is a single Perl file with a mere 1400+ lines of code.

Speaking of "borderline cases", such as mine:

IMNSHO 1400+ lines of Perl (or any) code don't fall into the category of "borderline cases" at all.

One of the opt-depend packages my disklow is using, "msmtp-mta", is containing a single symlink (/usr/bin/sendmail => msmtp). Perhaps, I should have a look at its PKGBUILD (it's most likely simply calling "ln -s" in its install() section).

package(), but yes: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packag... But what would the symbolic link be needed for?

...

More generally, why would you upload your project in a way that is targeted exclusively for Arch users? What if users of a different distro wanted to use your software?

Because I am going to provide the packages for them myself.

I don't think one can realistically package something for all the different distributions out there; you will inevitably end up excluding quite a number of platforms. I think this should have already been obvious enough while writing that sendmail-setup.txt, where it only explains the setup steps for Arch and CentOS, and for the others there is just: [/usr/share/doc/disklow/sendmail-setup.txt]

Please understand that there are so many different mail system setups in existence today, that it is impossible to cater for more than a few basic mail system configurations here.

Ó_ô And by not providing a distro-agnostic source for obtaining the code, this also discourages other people from stepping up and packaging it themselves; it's unnecessarily cumbersome and I kind of see it as a middle finger towards distribution packagers. And because https://{that_url_there}/repos is not browsable, people can't even know for what distributions the software has already been packaged; that's a middle finger also to the distribution *users*. And even for Arch users, reviewing the code becomes difficult, because (as already mentioned): On Mon, Sep 02, 2019 at 10:46:48 -0400, Eli Schwartz via aur-general wrote:

...

[…] regardless of where you host it, why would you upload it as a tarball checked into git?

Essentially, we lose all the nice VCS features, most notably the ability to conveniently track changes: we now have to obtain the tarballs for the old and the new version, extract them, and diff them manually. --Tinu