[PR PATCH] add haiti and its dependencies

[PR PATCH] add haiti and its dependencies

[noraj]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

There is a new pull request by noraj against master on the void-packages repository

https://github.com/noraj/void-packages haiti
https://github.com/void-linux/void-packages/pull/37804

add haiti and its dependencies
#### Testing the changes

- I tested the changes in this PR: **YES**
- This new package conforms to the [quality requirements](https://github.com/void-linux/void-packages/blob/master/Manual.md#quality-requirements): **YES**

#### Local build testing

- I built this PR locally for my native architecture, (x86_64)

#### Note

I don't know if haiti package could be called `haiti` instead of `ruby-haiti-hash`? Is `ruby-<gem_name>` for ruby dependencies and end-user software can be named without this prefix? If so is there a way to do something like

```shell
pkgname=haiti
_gemname=haiti-hash
version=0.6.1
build_style=gem
...

do_fetch() {
    gem install ${_gemname}
}

# or

distfiles="https://rubygems.org/downloads/${_gemname}-${version}.gem"
```

A patch file from https://github.com/void-linux/void-packages/pull/37804.patch is attached

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-haiti-37804.patch --]
[-- Type: text/x-diff, Size: 2432 bytes --]

From 533152dd527c89073a405e962b59ce189689ecea Mon Sep 17 00:00:00 2001
From: Alexandre ZANNI <16578570+noraj@users.noreply.github.com>
Date: Sat, 2 Jul 2022 19:19:31 +0200
Subject: [PATCH] add haiti and its dependencies

---
 srcpkgs/ruby-docopt/template     | 14 ++++++++++++++
 srcpkgs/ruby-haiti-hash/template | 16 ++++++++++++++++
 srcpkgs/ruby-paint/template      | 14 ++++++++++++++
 3 files changed, 44 insertions(+)
 create mode 100644 srcpkgs/ruby-docopt/template
 create mode 100644 srcpkgs/ruby-haiti-hash/template
 create mode 100644 srcpkgs/ruby-paint/template

diff --git a/srcpkgs/ruby-docopt/template b/srcpkgs/ruby-docopt/template
new file mode 100644
index 000000000000..e0011879522f
--- /dev/null
+++ b/srcpkgs/ruby-docopt/template
@@ -0,0 +1,14 @@
+# Template file for 'ruby-docopt'
+pkgname=ruby-docopt
+version=0.6.1
+revision=1
+build_style=gem
+short_desc="Command line option parser, that will make you smile"
+maintainer="Orphaned <orphan@voidlinux.org>"
+license="MIT"
+homepage="https://rubygems.org/gems/docopt"
+checksum=73f837ed376d015971712c17f7aafa021998b964b77d52997dcaff79d6727467
+
+post_install() {
+	vlicense LICENSE
+}
diff --git a/srcpkgs/ruby-haiti-hash/template b/srcpkgs/ruby-haiti-hash/template
new file mode 100644
index 000000000000..f3d84b0ccb03
--- /dev/null
+++ b/srcpkgs/ruby-haiti-hash/template
@@ -0,0 +1,16 @@
+# Template file for 'ruby-haiti-hash'
+pkgname=ruby-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"
+checksum=d2a2808cc1626bc5bb24c34a211645c2b3749af6f7d595a9a2d65d1be0d72a9f
+
+post_install() {
+	vlicense LICENSE.txt
+}
diff --git a/srcpkgs/ruby-paint/template b/srcpkgs/ruby-paint/template
new file mode 100644
index 000000000000..015c9e89a9e2
--- /dev/null
+++ b/srcpkgs/ruby-paint/template
@@ -0,0 +1,14 @@
+# Template file for 'ruby-paint'
+pkgname=ruby-paint
+version=2.2.1
+revision=1
+build_style=gem
+short_desc="Ruby paint manages terminal colors and effects"
+maintainer="Orphaned <orphan@voidlinux.org>"
+license="MIT"
+homepage="https://github.com/janlelis/paint"
+checksum=fd2c46f7fd1a1389d447e20f0ba2e8624792a7b64f827c146ef459ac5adfd005
+
+post_install() {
+	vlicense MIT-LICENSE.txt
+}

Re: New package: haiti-1.3.0

[sgn]

[-- Attachment #1: Type: text/plain, Size: 187 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/pull/37804#issuecomment-1173049508

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

Re: New package: haiti-1.3.0

[noraj]

[-- Attachment #1: Type: text/plain, Size: 157 bytes --]

New comment by noraj on void-packages repository

https://github.com/void-linux/void-packages/pull/37804#issuecomment-1173125035

Comment:
No you are right.

Re: New package: haiti-1.3.0

[noraj]

[-- Attachment #1: Type: text/plain, Size: 5053 bytes --]

New comment by noraj on void-packages repository

https://github.com/void-linux/void-packages/pull/37804#issuecomment-1173146895

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

> Error: 533152dd: 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:

```shell
# 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-}`.

```shell
# 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.

Re: [PR PATCH] [Updated] New package: haiti-1.3.0

[noraj]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

There is an updated pull request by noraj against master on the void-packages repository

https://github.com/noraj/void-packages haiti
https://github.com/void-linux/void-packages/pull/37804

New package: haiti-1.3.0
#### Testing the changes

- I tested the changes in this PR: **YES**
- This new package conforms to the [quality requirements](https://github.com/void-linux/void-packages/blob/master/Manual.md#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 https://github.com/void-linux/void-packages/pull/37804#issuecomment-1173146895

A patch file from https://github.com/void-linux/void-packages/pull/37804.patch is attached

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-haiti-37804.patch --]
[-- Type: text/x-diff, Size: 4236 bytes --]

From 3fb06d56e8728798ceb7e46ad5a804f64eb17d65 Mon Sep 17 00:00:00 2001
From: noraj <alexandre.zanni@europe.com>
Date: Sun, 3 Jul 2022 20:16:06 +0200
Subject: [PATCH] New package: haiti-1.3.0

---
 srcpkgs/haiti/template       | 84 ++++++++++++++++++++++++++++++++++++
 srcpkgs/ruby-docopt/template | 14 ++++++
 srcpkgs/ruby-paint/template  | 14 ++++++
 3 files changed, 112 insertions(+)
 create mode 100644 srcpkgs/haiti/template
 create mode 100644 srcpkgs/ruby-docopt/template
 create mode 100644 srcpkgs/ruby-paint/template

diff --git a/srcpkgs/haiti/template b/srcpkgs/haiti/template
new file mode 100644
index 000000000000..40d244473e3b
--- /dev/null
+++ b/srcpkgs/haiti/template
@@ -0,0 +1,84 @@
+# 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
+}
\ No newline at end of file
diff --git a/srcpkgs/ruby-docopt/template b/srcpkgs/ruby-docopt/template
new file mode 100644
index 000000000000..e0011879522f
--- /dev/null
+++ b/srcpkgs/ruby-docopt/template
@@ -0,0 +1,14 @@
+# Template file for 'ruby-docopt'
+pkgname=ruby-docopt
+version=0.6.1
+revision=1
+build_style=gem
+short_desc="Command line option parser, that will make you smile"
+maintainer="Orphaned <orphan@voidlinux.org>"
+license="MIT"
+homepage="https://rubygems.org/gems/docopt"
+checksum=73f837ed376d015971712c17f7aafa021998b964b77d52997dcaff79d6727467
+
+post_install() {
+	vlicense LICENSE
+}
diff --git a/srcpkgs/ruby-paint/template b/srcpkgs/ruby-paint/template
new file mode 100644
index 000000000000..015c9e89a9e2
--- /dev/null
+++ b/srcpkgs/ruby-paint/template
@@ -0,0 +1,14 @@
+# Template file for 'ruby-paint'
+pkgname=ruby-paint
+version=2.2.1
+revision=1
+build_style=gem
+short_desc="Ruby paint manages terminal colors and effects"
+maintainer="Orphaned <orphan@voidlinux.org>"
+license="MIT"
+homepage="https://github.com/janlelis/paint"
+checksum=fd2c46f7fd1a1389d447e20f0ba2e8624792a7b64f827c146ef459ac5adfd005
+
+post_install() {
+	vlicense MIT-LICENSE.txt
+}

Re: New package: haiti-1.3.0

[sgn]

[-- Attachment #1: Type: text/plain, Size: 184 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/pull/37804#issuecomment-1173186441

Comment:
It seems like noone will use it on Void Linux.

Re: [PR PATCH] [Closed]: New package: haiti-1.3.0

[sgn]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

There's a closed pull request on the void-packages repository

New package: haiti-1.3.0
https://github.com/void-linux/void-packages/pull/37804

Description:
#### Testing the changes

- I tested the changes in this PR: **YES**
- This new package conforms to the [quality requirements](https://github.com/void-linux/void-packages/blob/master/Manual.md#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 https://github.com/void-linux/void-packages/pull/37804#issuecomment-1173146895

Re: New package: haiti-1.3.0

[noraj]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

New comment by noraj on void-packages repository

https://github.com/void-linux/void-packages/pull/37804#issuecomment-1173680357

Comment:
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](https://docs.voidlinux.org/xbps/repositories/restricted.html) 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](https://github.com/vb-linux/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.

Re: New package: haiti-1.3.0

[sgn]

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/pull/37804#issuecomment-1174546869

Comment:
> 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 former (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, except you, who won't use Void Linux.

> I see there are [restricted repositories](https://docs.voidlinux.org/xbps/repositories/restricted.html) 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](https://github.com/vb-linux/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.

Re: New package: haiti-1.3.0

[sgn]

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/pull/37804#issuecomment-1174546869

Comment:
> 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 former (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, except you, who won't use Void Linux.

> I see there are [restricted repositories](https://docs.voidlinux.org/xbps/repositories/restricted.html) 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](https://github.com/vb-linux/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.

Re: New package: haiti-1.3.0

[sgn]

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/pull/37804#issuecomment-1174546869

Comment:
> 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, except you, who won't use Void Linux.

> I see there are [restricted repositories](https://docs.voidlinux.org/xbps/repositories/restricted.html) 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](https://github.com/vb-linux/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.

Re: New package: haiti-1.3.0

[sgn]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/pull/37804#issuecomment-1174546869

Comment:
> 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](https://docs.voidlinux.org/xbps/repositories/restricted.html) 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](https://github.com/vb-linux/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.

Re: New package: haiti-1.3.0

[noraj]

[-- Attachment #1: Type: text/plain, Size: 2252 bytes --]

New comment by noraj on void-packages repository

https://github.com/void-linux/void-packages/pull/37804#issuecomment-1174734157

Comment:
> 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? 

Re: New package: haiti-1.3.0

[sgn]

[-- Attachment #1: Type: text/plain, Size: 2996 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/pull/37804#issuecomment-1174883458

Comment:
> > 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

Re: New package: haiti-1.3.0

[noraj]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

New comment by noraj on void-packages repository

https://github.com/void-linux/void-packages/pull/37804#issuecomment-1174896778

Comment:
> 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.