AUR packaging issue

[brittyazel]

I noticed today an issue when installing an update to Terminix just a few hours after initially installing Terminix both with Pacaur. Since the update happened is close temporal proximity to the initial install, the build files were still in pacaur-tmp, and Terminix reported that the validity check failed. I was forced to delete the previous terminix build files out of tmp before the update would install.

The pacaur dev said this:

It seems terminix is a pre-compiled binary with a unique filename, regardless of the version. As stated in the terminix AUR comments, the package should be renamed to terminix-bin.

This said, I am not sure how to fix that issue without forcing redownload for all packages, which would be silly. This likely also happens when SRCDEST is enabled, which is even worst. I'll have a closer look, but my first recommendation would be to fix the issue upstream, either by using a naming scheme that includes the version, or by using an alternative PKGBUILD that compiles the package from source.

rmarquis/pacaur#420 (comment)

[phw]

Could be easily solved by having the version be part of the file name.

Having said this, I would actually prefer a real source package instead of the binary one. Is there a reason for this? Usually you see the packages build from binaries only for closed source software or in some cases for software that would require a lot of time to recompile.

[gnunn1]

I don't maintain the AUR packages anymore, packaging issues should be addressed with the packager by leaving a comment against the package itself so I'm closing this issue based on that.

As to the distribution of binaries, as I indicated to the AUR packager in issue #25, I generally prefer distributing binaries over building from source for the following reasons:

a. From time to time, I may have to patch libraries which isn't something that is easily handled when building from source. For example, a few versions of terminix needed to be built against a patched version of GtkD to fix some memory issues. Since D is a relatively uncommon choice for GTK apps, I like to leave myself the flexibility to do this.

b. As per A, the D toolchain isn't common like gcc so building from source means installing packages the user isn't likely to have. Not a huge deal, but I'm sure some users would start wondering why they have a .dub directory in home after doing the build. Additionally, some distros don't even have packages for all of the dependencies required, most notably dub, so binaries are the only option.

I just did a quick check of my own package list and I don't have a single -bin package on my system so I'm not too sure how common this actually is. I have a lot of AUR packages that are built from binaries including chrome, wps-office and visual-studio-code. The last one, visual-studio-code, is built from a binary as far as I can tell but source is available yet the packager opts not to do this.

[phw]

Regarding the -bin naming: I have seen this frequently, but only for packages where there was a choice between a source and a binary based package. I think the current naming is fine for this case.

[rmarquis]

The issue here is that you don't include the version in the provided filename (terminix.zip).

[gnunn1]

The version is in the path to the file.
On 15 Feb 2016 19:32, "rmarquis" notifications@github.com wrote:

The issue here is that you don't include the version in the provided
filename (terminix.zip).

—
Reply to this email directly or view it on GitHub
#82 (comment).

[rmarquis]

Yes, but the path to the file isn't downloaded to user system.

[dsboger-zz]

I may have misunderstood something, but it seems the problem is pacaur caches files while building a different version (i.e. a different PKGBUILD). I think the correct fix should be for pacaur to check that the pkgver changed and not to mix files.

[dsboger-zz]

I just pushed a modified PKGBUILD that should workaround this issue. It downloads the file with a different name including the version number. Please, add a comment to AUR if the problem persists.

[carlwgeorge]

@phw

Regarding the -bin naming: I have seen this frequently, but only for packages where there was a choice between a source and a binary based package. I think the current naming is fine for this case.

I disagree. The -bin suffix is a clear way to indicate to users that a pre-built binary is being used. It is important to indicate this because unlike compiling from source, a user has no way of verifying that a package using a pre-built binary was actually created from the source code that is available. Yes, many Arch users are fine with -bin AUR packages, but some are not, and there are no drawbacks to using the -bin naming convention.

[sagikazarmark]

I agree with @carlwgeorge.

Although there are many packages which contain binary, the preferred way (and the basic idea behind AUR) is to build packages from source. Exceptions can be compilation takes to much time, requires too much dependency, etc. It might be true in this case, but if there is a way to build it on user machines, then it should be the preferred way. That being said, you can still provide a -bin package and state it can be considered more stable than the building process, but that still lets your users to choose.