allow for different versions of poky

[g-oldfish]

allow for different versions of poky

[moto-timo]

@bobpaul if you want to tag containers with the poky version, go ahead and fork the repositories and deploy your own containers or pull the ones from our repositories and push them with your own tags. It has never been a design goal of crops to support older releases. We build containers for the currently supported versions of Yocto Project.

[moto-timo]

Supporting old versions was never a design goal of crops. The goal was to enable containerized builds of currently supported Yocto Project releases on Linux, Windows and Mac OS X. You are free to use an older git commit that supports your situation and build your own containers.

We have some very old EOL distributions available at https://hub.docker.com/r/crops/poky-eol

[g-oldfish]

Thanks for your quick response @moto-timo. Good to know. I'll look into rolling my own from an historic git commit.

[bobpaul]

@g-oldfish

at used to work with crops/ubuntu-18.04 image

Does your build actually require poky is installed in the OS environment? I've often had success by launching containers like

$ docker run --rm -it -v ${PWD}:/workdir crops/poky:ubuntu-18.04 --workdir=/workdir /bin/bash -c 'export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin; /bin/bash'

This unsets the PATH changes that were made by /opt/poky/${POKYVERSION}/environment-setup-x86_64-pokysdk-linux so that things like python3 will come from Ubuntu instead of poky. I think in this case, more native recipes need to be built, but this has usually worked for me.

Unfortunately they don't tag images to indicate the version of Poky that's installed to /opt (the debian-9 image has poky 4.1, the ubuntu-16.04 image has poky 3.1.13). I've noticed other projects often double tag images (ex like: debian-9 on image 6080058bf76b to show it's the most recent image with debian-9 as the base, but also debian-9_poky4.1 to show its built using poky4.1). If crops did that, users could just use crops/poky:ubuntu-18.04_poky3.5 if they needed an older image than what's in crops/poky:ubuntu_18.04 (which would always be the latest 18.04). But I assume docker hub has costs or size limitations that make keeping old images untenable.

[bobpaul]

@moto-timo

Just for clarity, I wasn't replying to you, I was replying to the user who had a concern. You referenced the policy reason, I expanded with some of the technical ramifications and a work around that has worked for me in the past. I realize now that speaking about the project "in front of you" probably came across as a bit passive aggressive and I wasn't thinking about that at the time, I do apologize.

It has never been a design goal of crops to support older releases.

You do. You literally do. Right now. Currently. Assuming "have published images for" means "supporting", crops currently has published images for Poky 4.1, 3.5, 3.1 and maybe others. It's hard to tell the tags don't tell us.

The convention in the docker community is to tag images based on the most relevant information in the container, which for crops is the version of poky. Tagging with the OS name is useful as some information can be extrapolated from that (such as what version of glibc, gcc, or python, but poky often overrides this with its own stuff).

Adding additional docker tags would bring poky in line with docker community norms and would not require breaking your existing tag structure nor would it imply storing old images. An image can (and very frequently should!) have multiple tags. Image 6d62d66ceb07 could be tagged crops:ubuntu-16.04, crops:poky-3.1.13, crops:poky-3.1, and crops:ubuntu-16.04_poky-3.1.13. You can certainly still delete that image if you ever upload a new ubuntu-16.04 image. You still wouldn't be "supporting old releases" anymore than you already are. The additional tags would just let someone look at the releases on docker hub and know the most important info (what version of poky is in this image) without cross referencing somewhere else or downloading all of the images to check. Which hopefully also means you stop having these conversations and have fewer questions on IRC and other places asking "which image?"

For example, users of Apache web server tend to either use latest because they don't care, or apache:ubuntu-20.04 because they're going to extend the image so ubuntu-20.04 is relevant, but they still want the latest apache. Or they get apache:2.6 because they want that version of Apache, and only that version of Apache (or nothing!) when they docker pull. This is just the convention in the docker world. It's like snake case in Python.

Would you entertain a pull-request meant to achieve this?

[moto-timo]

I do appreciate your concern and offer to help.

Please do not try to educate me on what the project does. I know you mean well, but you are again pushing some very tender buttons.

We have poky containers tagged with UPSTREAM DISTRO versions, because this is what the project was designed for. We only publish the latest "master" each week. Only the toaster-container repo is targeting multiple poky releases. If Docker hub is providing older containers, great. Bonus. NOT A DESIGNED BEHAVIOR.

We already have about a 12-16 container matrix, for all the distro-version variants. No one is sending pull requests for newer fedora, opensuse, etc. No one is fixing builds that fail on a given Friday.

Will I entertain a pull-request, yes. Will GitHub Actions completely-free-to-us-no-one-is-paying-them-any-money work? Probably? But, you must first address yocto-dockerfiles, because poky-container builds on top of that. And if what you send breaks in 6 months... then I will revert it to whatever state we are in now.