X-Original-To: alpine-aports@mail.alpinelinux.org Delivered-To: alpine-aports@mail.alpinelinux.org Received: from mail.alpinelinux.org (dallas-a1.alpinelinux.org [127.0.0.1]) by mail.alpinelinux.org (Postfix) with ESMTP id 4AD55DC03CE for ; Wed, 4 Nov 2015 11:32:29 +0000 (UTC) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id 97851DC0125 for ; Wed, 4 Nov 2015 11:32:28 +0000 (UTC) Received: by lbbes7 with SMTP id es7so14156694lbb.2 for ; Wed, 04 Nov 2015 03:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kampka_net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=7MNpvVFag4UiNPZNl6qDs/M57HH3T2OkdP5SVsPMMfM=; b=BcHaM9VaAA3CyhKJ27ADgCgSt5wcq1LP18cNbF81Z4FtiEmPbPnhLEjzT29Fs/jD7p tHoJs42L1vNh8bQKtqoBpFQTx8a7aGhue+IpDOVD8TqeNaoRjo9qQ3UKRTFpZfe7xg71 /x7oQ+1XJNVFEnG42QeZdwknSohuAV8WQ1eGmcMxc0xWwXFeY8cUIEOhuBhhphy8gt4P huLnk5LMMhXmQF/6YdrWcuaHjNKVpC3Ghaocuv49UJaykQf79mbuj04NfdtptvLPbSYe XjOI3caGxyETLM1qn0GWPYLFZ29oe0lWzjkieH/suZ42aHYcHk77Ca7BFf+3c1xntvcF owrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=7MNpvVFag4UiNPZNl6qDs/M57HH3T2OkdP5SVsPMMfM=; b=GdXGxKyRMskj/9tJra21z1B92+tH7c0w/5lx3M8nGx8zUNRmXiKx0h16H4qD/xvqN6 iuw2BZPPh6DPoUFLVcpwl+ZPFnuMtnPTLaTbDPZgXIREiEPPflQEq7Ib+rR+1+7ZBQ8P m01BYDfqf/RxHl02MmBJZScOYYWlQXdxGUecyb9pPkrWPfaFoqaVfCu1HakxwoU6+q2R jDlLAi3N5vvNk6EtbNttzAzr7IfoVL3xMyxOqZZbiCX9dBvUbZ4yTSKZPkaRUumx9xoD q/1o8/xHD8jETAihCf0lxst7hmKldajKTOZ+Vk7I3jgGsZC/JlQZTi4C0l21S4laq9tc yUmw== X-Gm-Message-State: ALoCoQme4l3wymwkxom7oztni11IqGMUVuZVJ4SNcBzrbeSl+cuRJgSnEZkXPSMalDJfQTGlE01i X-Received: by 10.112.199.100 with SMTP id jj4mr737987lbc.122.1446636746285; Wed, 04 Nov 2015 03:32:26 -0800 (PST) X-Mailinglist: alpine-aports Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 References: <1445177115-5446-1-git-send-email-christian@kampka.net> <20151104091345.1f8aba66@ncopa-desktop.alpinelinux.org> In-Reply-To: <20151104091345.1f8aba66@ncopa-desktop.alpinelinux.org> From: Christian Kampka Date: Wed, 04 Nov 2015 11:32:16 +0000 Message-ID: Subject: Re: [alpine-aports] [PATCH 1/2] testing/glock: new aport To: Natanael Copa Cc: alpine-aports@lists.alpinelinux.org Content-Type: multipart/alternative; boundary=001a11c2a99661bc600523b55da8 X-Virus-Scanned: ClamAV using ClamSMTP --001a11c2a99661bc600523b55da8 Content-Type: text/plain; charset=UTF-8 > > On Sun, 18 Oct 2015 16:05:14 +0200 > Christian Kampka wrote: > > > https://github.com/robfig/glock > > > > Glock is a command-line tool to lock dependencies to specific revisions, > > using a version control hook to keep those revisions in sync across a > team. > > --- > > testing/glock/APKBUILD | 67 > ++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 67 insertions(+) > > create mode 100644 testing/glock/APKBUILD > > I used the snapshot function and uploaded the tarball. > > However, the tarball I get must be different from the one you get. > > >>> glock: Checking sha512sums... > glock-0.0.20151018.tar.gz: FAILED > sha512sum: WARNING: 1 of 1 computed checksums did NOT match > Because the remote file above failed the sha512sum check it will be > deleted. > Rebuilding will cause it to re-download which in some cases may fix the > problem. > Deleting: glock-0.0.20151018.tar.gz > >>> ERROR: glock: all failed > > > I suspect that go pulls in whatever happens to the latest git at that > point of some dependency. That is to be expected, actually, since the tarball is gzip, so no two snapshots, although the may have identical content, will have different checksums due to the fact that the gzip header contains (amongst other things) a timestamp. A simple solution would be to refactor the patch to use uncompressed tar as the archive format, which will avoid this issue. > Also, they have not made any releases, which indicates that 1) program > is not ready for packaging, 2) program is not supposed to be packaged. > I am not keen on packaging this program either. It is needed as a build dependency of the dockerize package. Since the dockerize package has a snapshot function as well (for dealing with dependencies), I could easily remove this package by building glock once in the dockerize snapshot function and apply it to generate the snapshot. Since glock is not used for anything else, I think this might also be a feasible solution. I am open for suggestions how do properly package Go applications. > > Did anyone bring up this for Go community? I have the impression that > go developers wants you to use the Go package manager. > > Maybe we should just let the alpine linux users do that? Sadly, there is no "one" Go package manager, there are several attempts to solve this problem [1]. Glock is an attempt that has never really taken of, so rarely onyone uses it, but the dockerize author has not ported his program to anything like Godeps (which seems to be the most common choice atm). I don't think a good solution will present itself unless the go community can agree on a sane way of handling dependencies first. Cheers, Christian [1] https://github.com/golang/go/wiki/PackageManagementTools --001a11c2a99661bc600523b55da8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= On Sun, 18 Oct 2015 16:05:14 +0200
Christian Kampka <christian@kampka.net> wrote:

> https://github.com/robfig/glock
>
> Glock is a command-line tool to lock dependencies to specific revision= s,
> using a version control hook to keep those revisions in sync across a = team.
> ---
>=C2=A0 testing/glock/APKBUILD | 67 ++++++++++++++++++++++++++++++++++++= ++++++++++++++
>=C2=A0 1 file changed, 67 insertions(+)
>=C2=A0 create mode 100644 testing/glock/APKBUILD

I used the snapshot function and uploaded the tarball.

However, the tarball I get must be different from the one you get.

>>> glock: Checking sha512sums...
glock-0.0.20151018.tar.gz: FAILED
sha512sum: WARNING: 1 of 1 computed checksums did NOT match
Because the remote file above failed the sha512sum check it will be deleted= .
Rebuilding will cause it to re-download which in some cases may fix the pro= blem.
Deleting: glock-0.0.20151018.tar.gz
>>> ERROR: glock: all failed


I suspect that go pulls in whatever happens to the latest git at that
point of some dependency.

That is to be exp= ected, actually, since the tarball is gzip, so no two snapshots, although t= he may have identical content, will have different checksums due to the fac= t that the gzip header contains (amongst other things) a timestamp.
A simple solution would be to refactor the patch to use uncompressed tar= as the archive format, which will avoid this issue.
=C2=A0
=
Also, they have not made any releases, which indicates that 1) program
is not ready for packaging, 2) program is not supposed to be packaged.
<= /blockquote>

I am not keen on packaging this program eit= her. It is needed as a build dependency of the dockerize package.
Since the dockerize package has a snapshot function as well (for dealing w= ith dependencies), I could easily remove this package by building glock onc= e in the dockerize snapshot function and apply it to generate the snapshot.= Since glock is not used for anything else, I think this might also be a fe= asible solution.

I am open for suggestions how do properly package Go applications.

Did anyone bring up this for Go community? I have the impression that
go developers wants you to use the Go package manager.

Maybe we should just let the alpine linux users do that?
<= br>
Sadly, there is no "one" Go package manager, there = are several attempts to solve this problem [1]. Glock is an attempt that ha= s never really taken of, so rarely onyone uses it, but the dockerize author= has not ported his program to anything like Godeps (which seems to be the = most common choice atm).

I don't think a good = solution will present itself unless the go community can agree on a sane wa= y of handling dependencies first.

Cheers,
Christian

--001a11c2a99661bc600523b55da8-- --- Unsubscribe: alpine-aports+unsubscribe@lists.alpinelinux.org Help: alpine-aports+help@lists.alpinelinux.org ---