Hello Matthias, I am replying below to report some progress related to your ITP rkt bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782441
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). > > 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). > > 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.). Since today, it is possible to build stage1.aci with the "usr-from-host" flavor, meaning that the build does not require access to internet and it does not bundle systemd. When built in this way, rkt has a run-time dependency on systemd-v220. See: https://github.com/coreos/rkt/issues/686#issuecomment-108930462 I hope this will make things easier for packagers. Let me know if you have issues when trying this. > 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? > > Please have a look at the git repository [2] and give feedback :-). > > 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 _______________________________________________ Pkg-go-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
