Date: Thu, 27 Nov 2014 13:49:14 +0100
From: Natanael Copa <ncopa@alpinelinux.org>
To: Fabio Aires <fabioaires.web@gmail.com>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] [PATCH] testing/unix-privesc-check: new aport
Message-ID: <20141127134914.1ae958cf@ncopa-desktop.alpinelinux.org>
In-Reply-To: <1417030419-19458-1-git-send-email-fabioaires.web@gmail.com>
References: <1417030419-19458-1-git-send-email-fabioaires.web@gmail.com>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 26 Nov 2014 19:33:39 +0000
Fabio Aires <fabioaires.web@gmail.com> wrote:

> ---
>  testing/unix-privesc-check-svn/APKBUILD | 51 +++++++++++++++++++++++++++++++++
>  1 file changed, 51 insertions(+)
>  create mode 100644 testing/unix-privesc-check-svn/APKBUILD
> 
> diff --git a/testing/unix-privesc-check-svn/APKBUILD b/testing/unix-privesc-check-svn/APKBUILD
> new file mode 100644
> index 0000000..672dfaa
> --- /dev/null
> +++ b/testing/unix-privesc-check-svn/APKBUILD
> @@ -0,0 +1,51 @@
> +# Contributor: Fabio Aires <fabioaires.web@gmail.com>
> +# Maintainer: Fabio Aires <fabioaires.web@gmail.com>
> +
> +_pkgname="unix-privesc-check"
> +pkgname="$_pkgname-svn"
> +pkgver=362
> +pkgrel=1

unlike archlinux, we start pkgrel from 0.

> +pkgdesc="Shell script to check for simple privilege escalation vectors on Unix systems."
> +url="https://aur.archlinux.org/packages/unix-privesc-check-svn/"
> +arch="noarch"
> +license="GPL2"
> +depends=""
> +depends_dev="subversion"
> +makedepends="$depends_dev"
> +install=""
> +subpackages=""
> +source="https://aur.archlinux.org/packages/un/$pkgname/$pkgname.tar.gz"

...

> +
> +build() {
> +	cd "$_builddir"
> +	svn co http://$_pkgname.googlecode.com/svn/trunk

I am not really happy with this. Lets imagine that in 1 year ahead of
time, a user reports a bug. To be able to reproduce, a developer checks
out the affected revision from aports git and rebuilds it. But guess
what, he does not get same version as user reporting the problem,
instead he gets todays svn.

Also, we normally don't want provide 2 years support for a random
development revision. Instead we want upstream maintainer make a proper
release and we ship that. If upstream don't want support a release, why
should we do it?

If we want support a random svn revision anyway, then we should make a
release tarball of it and upload it some place. In other words, we will
be doing a release for upstream. (again, if upstream don't want take
responsability for their own code, why would we want do that?)

So I'd file a bug upstream, asking them to create a release.

If they reject make release, and you still want do it for them, then
I'd recommend using pkgver=0_svn362 and either use the archlinux
tarball that you fetch with $source or have svn to check out the exact
revision/tag instead of just grabbing current trunk.

-nc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---