[meta-virtualization] [PATCH 4/6] skopeo: add skopeo
Stefan Agner
stefan at agner.ch
Tue Sep 3 23:55:58 PDT 2019
On 2019-09-03 23:13, Bruce Ashfield wrote:
> On Tue, Sep 3, 2019 at 5:06 PM Mark Asselstine
> <mark.asselstine at windriver.com> wrote:
>>
>> On Tuesday, September 3, 2019 5:00:18 P.M. EDT Bruce Ashfield wrote:
>> > On Tue, Sep 3, 2019 at 4:41 PM Mark Asselstine
>> >
>> > <mark.asselstine at windriver.com> wrote:
>> > > On Tue, Sep 3, 2019 at 1:18 PM Bruce Ashfield <bruce.ashfield at gmail.com>
>> wrote:
>> > > > On Sun, Sep 1, 2019 at 4:35 PM Stefan Agner <stefan at agner.ch> wrote:
>> > > > > From: Stefan Agner <stefan.agner at toradex.com>
>> > > > >
>> > > > > skopeo is a command line utility that performs various operations on
>> > > > > container images and image repositories.
>> > > > >
>> > > > > skopeo can work with OCI images as well as the original Docker v2
>> > > > > images.
>> > > > >
>> > > > > The recipe originates from from meta-overc commit a497792. It has
>> > > > > been updated with the new project URL and v0.1.39.
>> > > >
>> > > > Nice!
>> > > >
>> > > > This was on my list to bring into meta-virtualization. Once I can
>> > > > confirm that it passes the meta-overc use cases, I'll merge this and
>> > > > drop the one from meta-overc.
>> > >
>> > > Which takes an item off my todo list. So double nice!
>> > >
>> > > Eventually I want to have this build -native and an addition to the
>> > > fetcher so it can be used to populate a rootfs with container images
>> > > from something like docker hub.
I was actually thinking about something along those lines too...
>> >
>> > I can honestly say "good luck wit that". There has to be an easier
>> > route than skopeo for that functionality.
>> >
>> > It simply has too many dependencies (and yet unused functionality) to
>> > be built -native. IMHO, it's just not the right tool for that job.
>> >
Skopeo Github days "Work with remote images registries - retrieving
information, images, signing content", doesn't seem that wrong either.
Sure, it comes with some extra features, and if there is a more
lightweight solution that would be nice. But then, its still better than
running a complete container engine to fetch an image, as some people do
:-)
>>
>> For sure and knowing that you have spent quite a bit of time looking at this I
>> am not about to argue against your assessment. I don't think this closes the
>> door on working with the skopeo folks to break up the functionality in order
>> to make this more feasible. At any rate, this is a ways off.
>
> ... or there just might be something in development for this already.
> I've heard of some oci / standards stuff that might address this, or
> maybe some of the alternate tools to skope are a better starting
> point.
>
> I'm just warning anyone that tries this, that they'll either have to
> split / drop functionality or chase a LOT of -native dependencies.
It does not seem that bad anymore now that we use the go build systems
dependency stuff. In the OE recipe there are only a hand full
dependencies now. Isn't it just a matter of invoking native go and
things should work out automagically?
--
Stefan
>
> Bruce
>
>>
>> MarkA
>>
>> > Bruce
>> >
>> > > MarkA
>> > >
>> > > > Bruce
>> > > >
>> > > > > Signed-off-by: Stefan Agner <stefan.agner at toradex.com>
>> > > > > ---
>> > > > >
>> > > > > recipes-containers/skopeo/skopeo_git.bb | 73
>> > > > > +++++++++++++++++++++++++
>> > > > > 1 file changed, 73 insertions(+)
>> > > > > create mode 100644 recipes-containers/skopeo/skopeo_git.bb
>> > > > >
>> > > > > diff --git a/recipes-containers/skopeo/skopeo_git.bb
>> > > > > b/recipes-containers/skopeo/skopeo_git.bb new file mode 100644
>> > > > > index 0000000..82d3f23
>> > > > > --- /dev/null
>> > > > > +++ b/recipes-containers/skopeo/skopeo_git.bb
>> > > > > @@ -0,0 +1,73 @@
>> > > > > +HOMEPAGE = "https://github.com/containers/skopeo"
>> > > > > +SUMMARY = "Work with remote images registries - retrieving
>> > > > > information, images, signing content" +LICENSE = "Apache-2.0"
>> > > > > +LIC_FILES_CHKSUM =
>> > > > > "file://src/import/LICENSE;md5=7e611105d3e369954840a6668c438584" +
>> > > > > +DEPENDS = " \
>> > > > > + gpgme \
>> > > > > + multipath-tools \
>> > > > > + btrfs-tools \
>> > > > > + glib-2.0 \
>> > > > > + ostree \
>> > > > > +"
>> > > > > +
>> > > > > +inherit go
>> > > > > +
>> > > > > +RDEPENDS_${PN} = " \
>> > > > > + gpgme \
>> > > > > + libgpg-error \
>> > > > > + libassuan \
>> > > > > +"
>> > > > > +
>> > > > > +SRC_URI = "git://github.com/containers/skopeo"
>> > > > > +
>> > > > > +SRCREV = "1cf1e06582142c522543560f2bc6d6756696e8ad"
>> > > > > +PV = "v0.1.39-dev+git${SRCPV}"
>> > > > > +GO_IMPORT = "import"
>> > > > > +
>> > > > > +S = "${WORKDIR}/git"
>> > > > > +
>> > > > > +inherit goarch
>> > > > > +inherit pkgconfig
>> > > > > +
>> > > > > +# This disables seccomp and apparmor, which are on by default in the
>> > > > > +# go package.
>> > > > > +EXTRA_OEMAKE="BUILDTAGS=''"
>> > > > > +
>> > > > > +do_compile() {
>> > > > > + export GOARCH="${TARGET_GOARCH}"
>> > > > > +
>> > > > > + # Setup vendor directory so that it can be used in GOPATH.
>> > > > > + #
>> > > > > + # Go looks in a src directory under any directory in GOPATH
>> > > > > but riddler + # uses 'vendor' instead of 'vendor/src'. We can
>> > > > > fix this with a symlink. + #
>> > > > > + # We also need to link in the ipallocator directory as that is
>> > > > > not under + # a src directory.
>> > > > > + ln -sfn . "${S}/src/import/vendor/src"
>> > > > > + mkdir -p
>> > > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo" +
>> > > > > ln -sfn "${S}/src/import/skopeo"
>> > > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo" +
>> > > > > ln -sfn "${S}/src/import/version"
>> > > > > "${S}/src/import/vendor/src/github.com/projectatomic/skopeo/version"
>> > > > > + export GOPATH="${S}/src/import/vendor"
>> > > > > +
>> > > > > + # Pass the needed cflags/ldflags so that cgo
>> > > > > + # can find the needed headers files and libraries
>> > > > > + export CGO_ENABLED="1"
>> > > > > + export CFLAGS=""
>> > > > > + export LDFLAGS=""
>> > > > > + export CGO_CFLAGS="${BUILDSDK_CFLAGS}
>> > > > > --sysroot=${STAGING_DIR_TARGET}" + export
>> > > > > CGO_LDFLAGS="${BUILDSDK_LDFLAGS} --sysroot=${STAGING_DIR_TARGET}" +
>> > > > > cd ${S}/src/import
>> > > > > +
>> > > > > + oe_runmake binary-local
>> > > > > +}
>> > > > > +
>> > > > > +do_install() {
>> > > > > + install -d ${D}/${sbindir}
>> > > > > + install -d ${D}/${sysconfdir}/containers
>> > > > > +
>> > > > > + install ${S}/src/import/skopeo ${D}/${sbindir}/
>> > > > > + install ${S}/src/import/default-policy.json
>> > > > > ${D}/${sysconfdir}/containers/policy.json +}
>> > > > > +
>> > > > > +INSANE_SKIP_${PN} += "ldflags"
>> > > > > --
>> > > > > 2.20.1
>> > > > >
>> > > > > --
>> > > > > _______________________________________________
>> > > > > meta-virtualization mailing list
>> > > > > meta-virtualization at yoctoproject.org
>> > > > > https://lists.yoctoproject.org/listinfo/meta-virtualization
>> > > >
>> > > > --
>> > > > - Thou shalt not follow the NULL pointer, for chaos and madness await
>> > > > thee at its end
>> > > > - "Use the force Harry" - Gandalf, Star Trek II
>> > > > --
>> > > > _______________________________________________
>> > > > meta-virtualization mailing list
>> > > > meta-virtualization at yoctoproject.org
>> > > > https://lists.yoctoproject.org/listinfo/meta-virtualization
>>
>>
>>
>>
More information about the meta-virtualization
mailing list