All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@gmail.com>
To: Stefan Agner <stefan@agner.ch>
Cc: Mark Asselstine <mark.asselstine@windriver.com>,
	meta-virtualization <meta-virtualization@yoctoproject.org>,
	Stefan Agner <stefan.agner@toradex.com>
Subject: Re: [PATCH 4/6] skopeo: add skopeo
Date: Wed, 4 Sep 2019 08:40:18 -0400	[thread overview]
Message-ID: <CADkTA4PDunctjHmTB4BzZRFWXOiEYhHHutnnebH8Yzyhb5fgEg@mail.gmail.com> (raw)
In-Reply-To: <2b0d0f0985204990398de33d423d7551@agner.ch>

On Wed, Sep 4, 2019 at 2:56 AM Stefan Agner <stefan@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@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@windriver.com> wrote:
> >> > > On Tue, Sep 3, 2019 at 1:18 PM Bruce Ashfield <bruce.ashfield@gmail.com>
> >> wrote:
> >> > > > On Sun, Sep 1, 2019 at 4:35 PM Stefan Agner <stefan@agner.ch> wrote:
> >> > > > > From: Stefan Agner <stefan.agner@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@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@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@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


  reply	other threads:[~2019-09-04 12:40 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-01 20:33 [PATCH 0/6] podman: add initial recipe Stefan Agner
2019-09-01 20:33 ` [PATCH 1/6] conmon: initial add Stefan Agner
2019-09-01 20:33 ` [PATCH 2/6] go-metalinter: add recipe for gometalinter Stefan Agner
2019-09-01 20:33 ` [PATCH 3/6] go-md2man: add md2man Stefan Agner
2019-09-01 20:33 ` [PATCH 4/6] skopeo: add skopeo Stefan Agner
2019-09-03 17:18   ` Bruce Ashfield
2019-09-03 20:41     ` Mark Asselstine
2019-09-03 21:00       ` Bruce Ashfield
2019-09-03 21:05         ` Mark Asselstine
2019-09-03 21:13           ` Bruce Ashfield
2019-09-03 21:29             ` Mark Asselstine
2019-09-04  6:55             ` Stefan Agner
2019-09-04 12:40               ` Bruce Ashfield [this message]
2019-09-01 20:33 ` [PATCH 5/6] cni: move cni tools to /usr/lib/cni Stefan Agner
2019-09-02  1:45   ` ChenQi
2019-09-03 17:28     ` Bruce Ashfield
2019-09-06 12:06       ` Stefan Agner
2019-09-06 12:42         ` Bruce Ashfield
2019-09-09 21:36           ` Stefan Agner
2019-09-01 20:33 ` [PATCH 6/6] podmon: add the Pod Manager tool Stefan Agner
2019-09-03 17:26   ` Bruce Ashfield
2019-09-09 21:30     ` Stefan Agner
2019-09-10 23:13       ` akuster
2019-09-03 17:20 ` [PATCH 0/6] podman: add initial recipe Bruce Ashfield
2019-09-04  6:44   ` Stefan Agner
2019-09-04 12:35     ` Bruce Ashfield

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADkTA4PDunctjHmTB4BzZRFWXOiEYhHHutnnebH8Yzyhb5fgEg@mail.gmail.com \
    --to=bruce.ashfield@gmail.com \
    --cc=mark.asselstine@windriver.com \
    --cc=meta-virtualization@yoctoproject.org \
    --cc=stefan.agner@toradex.com \
    --cc=stefan@agner.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.