[meta-virtualization] [PATCH 4/6] skopeo: add skopeo

Bruce Ashfield bruce.ashfield at gmail.com
Wed Sep 4 05:40:18 PDT 2019 

On Wed, Sep 4, 2019 at 2:56 AM Stefan Agner <stefan at agner.ch> wrote:
>
> 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.

Indeed. I use skopeo extensively, so I do like it. But I'm still
holding out hopes that something else will come out of the CNCF/OCI
working groups that is smaller, or at least a better defined and
focused.

When someone asked this before, the tooling really isn't the hard
part. It is going to be licensing, reproducibility, support, etc, etc.
So if we were able to do this, there's many landmines that aren't
technical.

> 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?

It wasn't that easy in my experimenting. All of the different disk
support was spidering through a lot of utilities that weren't easy to
build as -native.

But absolutely, the go packaging is better now, and we have just
captured / fetched what we need in most of the recipes, so there's no
longer 30 or 40 go recipes to extend to native (and of which 20 broke
when I tried it).

Cheers,

Bruce

>
> --
> 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
> >>
> >>
> >>
> >>



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

More information about the meta-virtualization mailing list