Mail archive

Re: [alpine-aports] [PATCH 1/2] testing/glock: new aport

From: Christian Kampka <>
Date: Wed, 04 Nov 2015 11:32:16 +0000

> On Sun, 18 Oct 2015 16:05:14 +0200
> Christian Kampka <> wrote:
> >
> >
> > 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

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



Received on Wed Nov 04 2015 - 11:32:16 GMT