[Solved] Query re. correctness of otf-crimson-text PKGBUILD

cfr · 2017-11-27 03:15:57

I currently have an outdated version of otf-crimson-text installed. I would like to update to the latest AUR package, but I'm trying to decide if I trust the PKGBUILD, which seems to me not quite right. However, I am certainly very far from expert in matters AUR and wonder if I'm just missing something really obvious, since nobody else seems in the least concerned.

My fundamental concern is that the package skips the checksum check and seems to pull a version which may or may not match the stated version. I think that the package should have a -git suffix and include a pkgver function, as it no longer seems to download a particular commit.

Upstream releases do not seem to include a version matching the version in the PKGBUILD. That is, the latter has 2014.06, while upstream has no releases between the end of 2013 and 11th October 2014, as far as I can tell. (I'm not very familiar with GitHub, either, even though I do use it a bit.)

Moreover, the PKGBUILD appears to pull master.zip, which suggests that it is pulling from the development branch. This is fine, but that would give a version of last year and I'd expect the package to be tagged -git and update its version number in the usual way. This would explain the lack of a checksum, however.

I wasn't sure quite how this worked, so I tried makepkg and got otf-crimson-text-1:2014.06-1-any.pkg.tar.xz, but looking at Crimson-Roman.otf , I find

Version:             Version 0.8 
Unique ID:           FontForge : Crimson Roman : 20-8-2016

Discussion on the AUR page suggest that an earlier version was altered to take account of some of these concerns. In that case, the package included a checksum and used a specific version. Hence, the package name was not adapted to reflect its being -git. However, the new version seems to omit that suffix and the suggested use of pkgver, together with the checksum, while actually packaging the latest git code with a version number I can't find anywhere. Moreover, the package still uses the obsolete -text in the package name, even though it draws from the GitHub successor (?) which lacks this.

The current version also lacks an installation script. However, I'm not clear if pacman hooks now take care of post-font-installation tasks automatically. (I know this changed, but am not sure of the details.)

Is the PKGBUILD correct as is? Or should it not be written this way?

# Maintainer:  Martin C. Doege <mdoege at compuserve dot com>
# Contributor: Hilton Medeiros <medeiros.hilton at gmail.com>

pkgname=otf-crimson-text
pkgver=2014.06
pkgrel=1
epoch=1
pkgdesc="A font family for book production in the tradition of beautiful oldstyle typefaces"
arch=('any')
url="https://github.com/skosch/Crimson/"
license=('OFL')
source=("$pkgname".zip::'https://github.com/skosch/Crimson/archive/master.zip')
md5sums=('SKIP')

package() {
  cd "$srcdir/Crimson-master/Desktop Fonts"
  install -d "$pkgdir/usr/share/fonts/OTF"
  install -m644 OTF/*.otf "$pkgdir/usr/share/fonts/OTF/"
}

AUR: https://aur.archlinux.org/packages/otf-crimson-text/

I can't tell if either the maintainer or contributor is currently active on AUR or not ....

Last edited by cfr (2017-11-28 01:06:31)

loqs · 2017-11-27 03:49:22

It is a git package in so much as it is using a dynamically generated archive of the the git repositories master branch.
As it is not using the git repository itself it can not access the git meta data that a pkgver() function requires.

pkgname=otf-crimson-text-git
pkgver=2014.06
pkgrel=1
epoch=1
pkgdesc="A font family for book production in the tradition of beautiful oldstyle typefaces"
arch=('any')
url="https://github.com/skosch/Crimson/"
license=('OFL')
makedepends=('git')
source=('git+https://github.com/skosch/Crimson.git')
md5sums=('SKIP')

pkgver() {
  cd "$srcdir"/Crimson
#  git describe --long --tags | sed 's/\([^-]*-g\)/r\1/;s/-/./g'
  printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

package() {
  cd "$srcdir"'/Crimson/Desktop Fonts'
  install -d "$pkgdir"/usr/share/fonts/OTF
  install -m644 OTF/*.otf "$pkgdir/usr/share/fonts/OTF/"
}

package() {
  cd "$srcdir"'/Crimson/Desktop Fonts'
  install -d "$pkgdir"/usr/share/fonts/OTF
  install -m644 OTF/*.otf "$pkgdir/usr/share/fonts/OTF/"
}

Adjusted PKGBUILD to use the git repository directly. No install function should be need because of /usr/share/libalpm/hooks/fontconfig.hook
Two alternate pkgver lines are provided depending on which format you think is more appropriate.
Edit:
added makedepends on git

Last edited by loqs (2017-11-27 11:08:29)

Trilby · 2017-11-27 12:26:39

cfr wrote:

...I'm trying to decide if I trust the PKGBUILD

There is nothing in it that could be malicious or untrustworthy beyond what is in loqs version.

Certainly the current PKGBUILD does many things incorrectly, it seems the packager(s) aren't very familiar with writing PKGBUILDs and there are some odd hacks and oversights. Loqs' version looks much more 'respectable' as being a standards-conforming PKGBUILD. And while this is good for many other reasons, any greater comfort or security you feel in using his is not well founded: in either case you're just getting whatever the latest stuff is in that github repo.

So what exactly do you mean by trust in this context? If you want to know whether it will work properly, just use it and see. If you want to know if there could be anything malicious in that github repo, loqs' well polished PKGBUILD provides no more protection from that than the existing hackish mess.

The PKGBUILD should be updated to meet the packaging standards - but this will have no effect on the security or trustworthiness of the built package.

cfr · 2017-11-27 17:11:13

Trilby wrote:

So what exactly do you mean by trust in this context? If you want to know whether it will work properly, just use it and see. If you want to know if there could be anything malicious in that github repo, loqs' well polished PKGBUILD provides no more protection from that than the existing hackish mess.

More 'trust' in the sense of 'what it says on the tin'. - 'trust' as 'truth in advertising'. That is, if it says it is using release 2014.06, is release 2014.06 what I'm getting? I suspected not. I'm not concerned that the package is doing anything malicious. Or even that it is inadvertently doing anything less securely than a -git package would. (And I don't think -git packages are significantly less secure than any others: checksums provide at best an extremely minimal increase in security, as far as I can tell.) But I like packages to be trustworthy in the sense of being accurate/truthful.

Trilby · 2017-11-27 17:23:27

cfr wrote:

... if it says it is using release 2014.06, is release 2014.06 what I'm getting

Oh, then in that case, yeah, the current PKGBUILD is complete crap - loqs' is trustworthy on that criteria.

cfr · 2017-11-28 00:52:38

loqs wrote:

Adjusted PKGBUILD to use the git repository directly. No install function should be need because of /usr/share/libalpm/hooks/fontconfig.hook
Two alternate pkgver lines are provided depending on which format you think is more appropriate.

This is great - thanks very much. It would be great if this could somehow replace the current one in AUR. I believe the -text in the package name should probably be dropped to reflect the current upstream name.

Slithery · 2017-11-28 00:57:16

Have you tried contacting the maintainer?

You can always file an orphan request, if the maintainer doesn't respond then you can take over the package.

Last edited by Slithery (2017-11-28 00:58:14)

Trilby · 2017-11-28 01:19:58

While taking over the current one would be the best way to get it deleted / merged, there really is no need as the proposed changes include a new package name. The new one can be submitted now.

loqs · 2017-11-28 01:24:38

cfr wrote:

I believe the -text in the package name should probably be dropped to reflect the current upstream name.

Given the naming confusion I left the text in either with or without seems fine to me.
One thing I did miss was if the package name was changed with or without the text element the epoch could be dropped.
The current maintainer would need to request a package name change.
Edit:
Posting at the same time as Trilby who makes an excellent point its quite normal to have both a git and none git version of a package in AUR.
If the current package is not supposed to be the git version then adding a git version makes perfect sense.

Last edited by loqs (2017-11-28 01:26:46)

cfr · 2017-11-28 01:45:02

slithery wrote:

Have you tried contacting the maintainer?

loqs wrote:

The current maintainer would need to request a package name change.

I left comments earlier this month on the AUR page. However, after starting this thread, I noticed that the AUR page gives the maintainer as 'None', so I'm not sure that the maintainer listed in the PKGBUILD is still correct.

I changed the name to crimson locally mostly to keep it separate from the AUR package in my own mind. I wasn't aware of that 'naming confusion' note - I just saw the comments on the AUR page and noticed that the URL had changed the name in moving from sourceforge to github (if I remember rightly).

Trilby · 2017-11-28 02:55:27

cfr wrote:

I noticed that the AUR page gives the maintainer as 'None'

Ah, in that case no need to create a new package and hope the old one eventually gets deleted. Just adopt the old one (if you're willing to maintain it) and request the name change and/or merge with the new one.

cfr · 2017-11-29 02:05:44

Trilby wrote:

cfr wrote:
I noticed that the AUR page gives the maintainer as 'None'
Ah, in that case no need to create a new package and hope the old one eventually gets deleted. Just adopt the old one (if you're willing to maintain it) and request the name change and/or merge with the new one.

I'm not sure this is a good idea. I've never done this and I'm not even the one who redid the PKGBUILD. I worry I would make even more of a mess of it.

Lone_Wolf · 2017-11-29 15:07:20

I think the most important requirement for maintaining aur programs is motivation .

If having a good working otf-crimson package matters to you, go for it.
there are plenty of people around to help with issues.

Arch Linux

#1 2017-11-27 03:15:57

[Solved] Query re. correctness of otf-crimson-text PKGBUILD

#2 2017-11-27 03:49:22

Re: [Solved] Query re. correctness of otf-crimson-text PKGBUILD

#3 2017-11-27 12:26:39

Re: [Solved] Query re. correctness of otf-crimson-text PKGBUILD

#4 2017-11-27 17:11:13

Re: [Solved] Query re. correctness of otf-crimson-text PKGBUILD

#5 2017-11-27 17:23:27

Re: [Solved] Query re. correctness of otf-crimson-text PKGBUILD

#6 2017-11-28 00:52:38

Re: [Solved] Query re. correctness of otf-crimson-text PKGBUILD

#7 2017-11-28 00:57:16

Re: [Solved] Query re. correctness of otf-crimson-text PKGBUILD

#8 2017-11-28 01:19:58

Re: [Solved] Query re. correctness of otf-crimson-text PKGBUILD

#9 2017-11-28 01:24:38

Re: [Solved] Query re. correctness of otf-crimson-text PKGBUILD

#10 2017-11-28 01:45:02

Re: [Solved] Query re. correctness of otf-crimson-text PKGBUILD

#11 2017-11-28 02:55:27

Re: [Solved] Query re. correctness of otf-crimson-text PKGBUILD

#12 2017-11-29 02:05:44

Re: [Solved] Query re. correctness of otf-crimson-text PKGBUILD

#13 2017-11-29 15:07:20

Re: [Solved] Query re. correctness of otf-crimson-text PKGBUILD

Board footer