New package: haiti-1.3.0

[noraj]

Testing the changes

• I tested the changes in this PR: YES
• This new package conforms to the quality requirements: YES

Local build testing

• I built this PR locally for my native architecture x86_64 and also for armv7l

Note

I have a hard time calling the package haiti instead of ruby-haiti-hash? see #37804 (comment)

[sgn]

It seems like you aren't going to use Void Linux?

[noraj]

No you are right.

[noraj]

https://github.com/void-linux/void-packages/runs/7163511132?check_suite_focus=true

Error: 533152d: subject does not follow CONTRIBUTING.md guildelines

The cause is not very detailed by I guess it's the commit description that is wrong.

By the way I was trying to change the package name to the tool name and thought this would have been enough:

# Template file for 'haiti'
pkgname=haiti
_gemname=haiti-hash
version=1.3.0
revision=1
build_style=gem
depends="ruby-docopt ruby-paint"
short_desc="Hash type identifier (CLI & lib)"
maintainer="Orphaned <orphan@voidlinux.org>"
license="MIT"
homepage="https://noraj.github.io/haiti/"
changelog="https://github.com/noraj/haiti/blob/master/docs/CHANGELOG.md"
distfiles="https://rubygems.org/downloads/${_gemname}-${version}.gem>${pkgname}-${version}.gem"
checksum=d2a2808cc1626bc5bb24c34a211645c2b3749af6f7d595a9a2d65d1be0d72a9f

post_install() {
	vlicense LICENSE.txt
}

But I have a hard time doing that since https://github.com/void-linux/void-packages/blob/master/common/build-style/gem.sh assume that ${pkgname} or ${pkgname#ruby-} = gem file name = the gem name, and https://github.com/void-linux/void-packages/blob/master/common/build-style/gemspec.sh assumes ${pkgname} or ${pkgname#ruby-} = gem file name = the gem name = gemspec file name.

But since I have pkgname = haiti, gemname = haiti-hash, and gamespec = haiti. I can easily rename haiti-hash-1.3.0.gem to haiti-1.3.0.gem but /host/sources/by_sha256 will still use <sha256>_haiti-hash-1.3.0.gem. But some variables in the helper such as _INSTDIR=${DESTDIR}/${_GEMDIR}/gems/${pkgname#ruby-}-${version} are using pkgname. If feels like there should be a gemname variable available that would be equal by default to ${pkgname#ruby-} but that could be overwritten to overcome those issues.

So in order to manage that I have to re-define the whole do_install() just to make _INSTDIR and the last sed use ${_gemname} instead of ${pkgname#ruby-}.

# Template file for 'haiti'
pkgname=haiti
_gemname=haiti-hash
version=1.3.0
revision=1
build_style=gem
depends="ruby-docopt ruby-paint"
short_desc="Hash type identifier (CLI & lib)"
maintainer="Orphaned <orphan@voidlinux.org>"
license="MIT"
homepage="https://noraj.github.io/haiti/"
changelog="https://github.com/noraj/haiti/blob/master/docs/CHANGELOG.md"
distfiles="https://rubygems.org/downloads/${_gemname}-${version}.gem>${pkgname}-${version}.gem"
checksum=d2a2808cc1626bc5bb24c34a211645c2b3749af6f7d595a9a2d65d1be0d72a9f

do_install() {
	: ${gem_cmd:=gem}

	local _GEMDIR _INSTDIR
	
	_GEMDIR=$($gem_cmd env gemdir)
	_INSTDIR=${DESTDIR}/${_GEMDIR}/gems/${_gemname}-${version}

	$gem_cmd install \
		--local \
		--install-dir ${DESTDIR}/${_GEMDIR} \
		--bindir ${DESTDIR}/usr/bin \
		--ignore-dependencies \
		--no-document \
		--verbose \
		${XBPS_SRCDISTDIR}/${pkgname}-${version}/${pkgname#ruby-}-${version}.gem

	# Remove cache
	rm -rf ${DESTDIR}/${_GEMDIR}/cache

	# Remove ext directory. they are only source code and configuration
	# The actual extensions are guarded in an arch path
	rm -rf ${_INSTDIR}/ext

	# Remove installed tests and benchmarks
	rm -rf ${_INSTDIR}/{test,tests,autotest,benchmark,benchmarks,script,examples,demo}

	# Remove files shipped on the root of the gem, most of the time they are useless
	find ${_INSTDIR} -maxdepth 1 -type f -delete

	# Remove unnecessary files
	find ${DESTDIR}/${_GEMDIR}/extensions \( -name mkmf.log -o -name gem_make.out \) -delete

	# Place manpages in usr/share/man/man[0-9]
	if [ -d ${_INSTDIR}/man ]; then
		find ${_INSTDIR}/man -type f -name '*.[0-8n]' | while read -r m; do
			vman ${m}
		done
	fi

	rm -rf "${_INSTDIR}/man"

	# Place executables in /usr/bin
	if [ -d "${_INSTDIR}/bin" ]; then
		for f in "${_INSTDIR}"/bin/*; do
			vbin "${f}"
		done
	fi

	rm -rf ${_INSTDIR}/bin

	# Place conf files in their places
	if [ -d ${_INSTDIR}/etc ]; then
		find ${_INSTDIR}/etc -type f | while read -r c; do
			vmkdir ${c%/*}/
			mv ${c} "${DESTDIR}/${c##*${_INSTDIR}/etc/}/"
		done
	fi

	rm -rf ${_INSTDIR}/etc

	# Ignore the ~> operator, replace it with >=
	sed 's|~>|>=|g' \
		-i ${DESTDIR}/${_GEMDIR}/specifications/${_gemname}-${version}.gemspec
}

post_install() {
	vlicense LICENSE.txt
}

Bit this seems hardly maintainable.

So the 3 options are :

• Add a optional gemname variable in templates
• Use do_install() override but it's hard to maintain since each template using this method would have to be changed when common/build-style/gem.sh changes
• Keep ruby-<gem-name> for pkgname which is less end-user friendly (goatcounter is goatcounter not go-goatcounter or you-get pkgname is you-get and not python-you-get)

I wonder if there is an easy alternative I'm missing.

[sgn]

It seems like noone will use it on Void Linux.

[noraj]

It's a bit harsh to assume that and say it like that but ok, I guess security tools are not welcome on this distro.
But if you think too few users will use it, it's not necessary needed to include and build it by default. I see there are restricted repositories on Void so they are included in void-packages but need to be built manually by users. Else I guess I'll have to submit it to non-official VUR.
I'm new to Void and I'm discovering it, I took a lot of time to submit a PR and test it and reading the doc rather than opening a feature request issue. I was expecting a more welcoming answer even for a refusal.

[sgn]

It's a bit harsh to assume that and say it like that

Sorry, but I only assume that because you wrote the tool and try to submit this tool to multiple distro.

but ok, I guess security tools are not welcome on this distro.

Security tools are very welcomed in this distro. In facts, all tools which will be used by our users will be welcomed.
However, security tools should go under auditing before introduction. And tools should be introduced by users who will USE the tools ON Void Linux. I can see the former (as you wrote it) but not the latter (noone specifically asked for it).

But if you think too few users will use it, it's not necessary needed to include and build it by default.

I think NO Void Linux users will use it. Evident: noone ever asked for it while haiti was release a stable release for more than 1 year, except you, who won't use Void Linux.

I see there are restricted repositories on Void so they are included in void-packages but need to be built manually by users.

Maintaining a software also costs. Build and distribute are easy, since machine are cheap. Human cost is not.

Else I guess I'll have to submit it to non-official VUR.

I only know VUR because of your comments.

I'm new to Void and I'm discovering it, I took a lot of time to submit a PR and test it and reading the doc rather than opening a feature request issue. I was expecting a more welcoming answer even for a refusal.

[noraj]

Sorry, but I only assume that because you wrote the tool and try to submit this tool to multiple distro.

The tool is from 2019 and have already spread. I'm not actually trying to ship it in more distro for fame or whatever but because I had feedback from users that they don't want to gem install on their distro so providing them a distro package is easier and more maintainable for them. That's all.

Security tools are very welcomed in this distro. In facts, all tools which will be used by our users will be welcomed.
However, security tools should go under auditing before introduction. And tools should be introduced by users who will USE the tools ON Void Linux. I can see the former (as you wrote it) but not the latter (noone specifically asked for it).

That make sense.

I think NO Void Linux users will use it. Evident: noone ever asked for it while haiti was release a stable release for more than 1 year, except you, who won't use Void Linux.

I know a least one Void user which use it but he is using the docker image or the distro package in an ArchLinux package because there is no Void package. Maybe there are more that are actually using a workaround and don't feel the need to request for it but would switch to void package if available. But again it make sens to me to not include it if it targets too few users. On ArchLinux there is an user repository (AUR) where people can vote for package, so eventually a dev can provide it's tool on the AUR and if it's a massive success and lot of people vote for it sometimes ArchLinux dev offers to include the tool in the official repo. Unfortunately there is no such a mechanism for Void.

Maintaining a software also costs. Build and distribute are easy, since machine are cheap. Human cost is not.

For that I can maintain the Void package and bump / test it at each Haiti release, I put orphan because I thought it required the name of an official team member.

I only know VUR because of your comments.

Yay, it seems very little know. Maybe you know another more popular void user repository alternative?

[sgn]

Sorry, but I only assume that because you wrote the tool and try to submit this tool to multiple distro.

The tool is from 2019 and have already spread.

In haiti repository, I only see BlackArch, and FreeBSD ports, also AUR (which, I think, everyone can submit) and Gentoo overlay.
So, I'm not sure how you define "spread".
This isn't a confrontation. It's just my observation.

I'm not actually trying to ship it in more distro for fame or whatever but because I had feedback from users that they don't want to gem install on their distro so providing them a distro package is easier and more maintainable for them. That's all.

Citation requested, please.

Security tools are very welcomed in this distro. In facts, all tools which will be used by our users will be welcomed.
However, security tools should go under auditing before introduction. And tools should be introduced by users who will USE the tools ON Void Linux. I can see the former (as you wrote it) but not the latter (noone specifically asked for it).

That make sense.

I think NO Void Linux users will use it. Evident: noone ever asked for it while haiti was release a stable release for more than 1 year, except you, who won't use Void Linux.

I know a least one Void user which use it but he is using the docker image or the distro package in an ArchLinux package because there is no Void package. Maybe there are more that are actually using a workaround and don't feel the need to request for it but would switch to void package if available.

Citation requested, again.

But again it make sens to me to not include it if it targets too few users.

No, it's fine to be used by a few users, (you're not using Void Linux, so I don't think you're counted).

On ArchLinux there is an user repository (AUR) where people can vote for package, so eventually a dev can provide it's tool on the AUR and if it's a massive success and lot of people vote for it sometimes ArchLinux dev offers to include the tool in the official repo. Unfortunately there is no such a mechanism for Void.

Users can request to package it. See https://github.com/void-linux/void-packages/issues?q=is%3Aissue+is%3Aopen+label%3Arequest for current requests.

Maintaining a software also costs. Build and distribute are easy, since machine are cheap. Human cost is not.

For that I can maintain the Void package and bump / test it at each Haiti release, I put orphan because I thought it required the name of an official team member.

Maintaining a distro isn't simply bump version of a package, but also integrate with other parts of system.

I only know VUR because of your comments.

Yay, it seems very little know. Maybe you know another more popular void user repository alternative?

No, I don't

[noraj]

In haiti repository, I only see BlackArch, and FreeBSD ports, also AUR (which, I think, everyone can submit) and Gentoo overlay.
So, I'm not sure how you define "spread".
This isn't a confrontation. It's just my observation.

I didn't meant spread in term of distro coverage, but spread in term of it's known and used by security enthusiast peoples.

Citation requested, please. (gem install vs distro)

It's mostly oral feedback or Discord DMs. At least in the pentest community people are familiar with python and not afraid of pip install stuff but when it comes to cpan, npm, gem, cargo, etc. they are lost and don't know what to do so they prefer distro packages.

Citation requested, again. (I know 1 void user)

This is a personal friend of mines, I have no public record of my friend showing he use Void.

Maintaining a distro isn't simply bump version of a package, but also integrate with other parts of system.

Thank you, has a BA dev I know that, that's why I also offered to test and stuff.

But anyway, thanks for the discussion, I'll just add the Void template to haiti repo as in the end whatever the choice of where it's stored it will be me maintaining it.