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 <[email protected]> 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 > [email protected] > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers > -- Best regards, Michael
_______________________________________________ Pkg-go-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
