[pkg-go] Request for Review: rkt packaging

[Michael Stapelberg]

I just realized you didn’t get a reply to this yet, sorry for the late
reply. See below:

On Wed, Apr 22, 2015 at 8:01 PM, Matthias Schmitz <matthias at sigxcpu.org>
wrote:

> Hi everyone,
>
> i started to package rkt [1] and pushed it
> to the Alioth pkg-go git repository [2].
>
> I have some questions about the packaging of Go applications in general
> and some questions about the rkt packaging.
>
> First: I use dh_golang as described on the pkg-go-Alioth page[3] and as
> rkt is a binary it should not install its source in /usr/share/golang.
> Is their a way to suppress the installation of the source? At the
> moment i just "rm" the usr/share/gocode/rkt in debian/rules (as i saw in
> the docker debian/rules).
>

Using rm is fine.


>
> The rkt source build seven binaries but only two of them (rkt, actool)
> are for the user (living in /usr/bin/) and the other five are for
> use in the stage1.aci (Application Image Container, please see the
> architecture description here: [4]). Is there a more elegant way to
> install them not in usr/bin as the way i used (rm them from usr/bin and
> install also by rkt.install).
>

I can’t find rkt.install (anymore?) in the repository, so perhaps you’ve
already solved this…?


>
> The creation of the stage1.aci is also a thing i am unsure how to
> do that. Upstream builds the stage1.aci by downloading a pxe.img and
> extracting systemd and other stuff and create the Image. This is of
> course a "no way action" for Debian. What do you thing about shipping a
> script with rkt which would run the same actions like upstream
> (download coreos pxe.img and so on) to create the image by the user? I
> thing it could be hard to create the image only from Debian's own
> packages (installing systemd as Build-Dependency and copying that to
> the image e.g.).
>

You already got a reply to this further down the email thread.


>
> But the thing that worries me most is the heavy use of embedded source
> code copies in the upstream repository. It ships all its Godeps
> committed in its own git repository. As i understand the Debian Policy
> 4.13 [5] those "Convenience copies of code" are not allowed.
> How would i address this problem?
>

You’re correct in that bundling source code is heavily discouraged. You’d
solve the problem by creating Debian packages for all the bundled packages
(where necessary, some might already be packaged).


>
> Please have a look at the git repository [2] and give feedback :-).
>

>From what I can see currently, the repository looks good :).


>
> Best wishes,
> Matthias
>
> [1] https://github.com/coreos/rkt
> [2] https://anonscm.debian.org/cgit/pkg-go/packages/rkt.git/
> [3] https://pkg-go.alioth.debian.org/packaging.html
> [4]
>
> https://github.com/coreos/rkt/blob/master/Documentation/devel/architecture.md
> [5] https://www.debian.org/doc/debian-policy/ch-source.html
>
> _______________________________________________
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20150611/cbfebf0d/attachment.html>