Skip to content

Images with Perl 5.8..5.24 are built with old version of git #100

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
atoomic opened this issue Apr 10, 2021 · 20 comments
Closed

Images with Perl 5.8..5.24 are built with old version of git #100

atoomic opened this issue Apr 10, 2021 · 20 comments

Comments

@atoomic
Copy link
Member

atoomic commented Apr 10, 2021

The docker images from 5.24 to 5.8 (and probably older) are providing a git version not supported anymore by GitHub
We should consider rebuilding all these images with an updated distro.

When trying to use these images to smoke Perl distro for example p5-TOML-XS here, we can see that the actions/checkout@v2 fallback to using the GitHub REST API instead of using git binary directly....

We can assume that git < 2.18 has some CVEs that we do not want to use...
To create a local Git repository instead, add Git 2.18 or higher to the PATH

actions/checkout output

Run actions/checkout@v2
/usr/bin/docker exec  18b7c324aeb62970e6c428445947204a2c2b0def760b624299cbca1e11e2dae8 sh -c "cat /etc/*release | grep ^ID"
Syncing repository: FGasper/p5-TOML-XS
Getting Git version info
Deleting the contents of '/__w/p5-TOML-XS/p5-TOML-XS'
The repository will be downloaded using the GitHub REST API
To create a local Git repository instead, add Git 2.18 or higher to the PATH
Downloading the archive
Writing archive to disk
Extracting the archive
/bin/tar xz -C /__w/p5-TOML-XS/p5-TOML-XS/2c9a3eb2-f909-4461-b74d-60632e3ee131 -f /__w/p5-TOML-XS/p5-TOML-XS/2c9a3eb2-f909-4461-b74d-60632e3ee131.tar.gz
Resolved version FGasper-p5-TOML-XS-6d72200

copy: @FGasper / @oalders

discussed here Perl/docker-perl-tester#18

@oalders
Copy link
Collaborator

oalders commented Apr 11, 2021

Would be nice to address the issue at this level.

@yosifkit
Copy link

For the images on Docker Hub (https://hub.docker.com/_/perl), only the tags listed in the official-images library/perl file are built/rebuilt: docker-library/official-images library/perl. See also https://github.com/docker-library/faq/#an-images-source-changed-in-git-now-what.

(I would guess that older versions fall under "unsupported" as per policy: https://perldoc.perl.org/perlpolicy#MAINTENANCE-AND-SUPPORT) From the view of official-images, we will build whatever Perl "supports" and puts in the library file (assuming its FROM is also still supported).


FYI, the perl:5.8 image was last built ~5 years ago:

$ docker pull perl:5.8
5.8: Pulling from library/perl
Image docker.io/library/perl:5.8 uses outdated schema1 manifest format. Please upgrade to a schema2 image for better future compatibility. More information at https://docs.docker.com/registry/spec/deprecated-schema-v1/
e5ad7970bc69: Pull complete 
a3ed95caeb02: Pull complete 
d54f4f30cd6f: Pull complete 
bbe5878d8681: Pull complete 
1df3bb332f6a: Pull complete 
3bba0561f23e: Pull complete 
b414ce41cb09: Pull complete 
4fd3658c936c: Pull complete 
662129b914c0: Pull complete 
Digest: sha256:52e63f8c1919222872e82c24737f9f546b640eb166021c8ecd0ebd71420ceb64
Status: Downloaded newer image for perl:5.8
docker.io/library/perl:5.8
$ docker images perl
REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
perl         5.8       481e5a47c367   5 years ago   715MB

@zakame
Copy link
Member

zakame commented Apr 13, 2021

Thanks @atoomic @oalders for reporting, and @yosifkit for the follow-up!

I suppose the best we can do for all these older/unsupported perls would be to document these needing their git updated - also for the CI use-case, it might be better to use a separate container that does git operations separate from perl-specific ones (and as such this is already the case in GitHub Actions.) Would that work for you?

See also #88 - we'll likely get an even newer git version from the Debian 11 base when 5.34 drops.

@oalders
Copy link
Collaborator

oalders commented Apr 14, 2021

Thanks @zakame! Based on the support policy, I think documenting that would be helpful. On our end, if we need a newer Git, we can figure it out. :)

@atoomic
Copy link
Member Author

atoomic commented Apr 14, 2021

Correct me if I do not understand it right, you want to document it on your side, and on our side we take care of updating git for these legacy images we are using as base for our CI ones?
That works for me

@tianon
Copy link
Contributor

tianon commented Apr 14, 2021

Another option would be a one-time rebuild of these older versions (add them to library/perl, wait for all the builds, then remove them again).

I'm curious though, what's the use case for testing against unsupported/EOL versions of Perl?

@atoomic
Copy link
Member Author

atoomic commented Apr 14, 2021

A typical use case is to publish a distribution to CPAN... and using GitHub workflow to check if regressions are introduced

@tianon
Copy link
Contributor

tianon commented Apr 15, 2021

I guess what I'm trying to ask is where does the demand for EOL Perl versions come from? Are there specific reasons why users might end up asking for / using EOL versions of Perl and thus need you to test against them?

For example, if some non-trivial number of users are running Ubuntu 16.04 with Perl 5.22, then it probably makes sense to run the tests in that environment directly with the version of Perl they're using instead of a stock upstream Perl 5.22, for which a Dockerfile that does FROM ubuntu \n RUN apt-get update && apt-get install -y perl might be sufficient and test what the real end-goal is. 😅

@oalders
Copy link
Collaborator

oalders commented Apr 15, 2021

The Perl ecosystem has, for better or worse, an obsession with backwards compatibility. So, many authors of CPAN modules will support minimum Perl versions which are quite old. I work on some stuff that gets tested back to 5.8, which will turn 20 next year. Chances are you can work on a very old Perl and still run some fairly recent code. With many authors there's a feeling that they'll support the older Perls if there's not too much standing on your head involved, so it's not uncommon to want specifically to test a 5.8, 5.10 etc just to ensure you're not introducing new failures for users who may or may not actually exist.

@tianon
Copy link
Contributor

tianon commented Apr 15, 2021

Ahh, makes sense; thank you for the additional detail. 😄 ❤️

So in that light, I think doing a one-time back-fill rebuild is probably a good, safe option, especially since all the necessary Dockerfiles are already conveniently maintained here. 😄

@atoomic
Copy link
Member Author

atoomic commented Apr 15, 2021

This would be awesome!
Thanks in advance
Please ping this case once the images are available

@tianon
Copy link
Contributor

tianon commented Apr 15, 2021

Ah, looking into this deeper, I think one sticking point is going to be that many of those older images are on Debian Jessie -- we'll need to bump those to at least Debian Stretch (which is the underlying source of the issue here anyhow).

Pinging the image maintainers, @PeterMartini @zakame -- what are your thoughts here? Do you think it's going to be a big lift getting these to compile successfully on a slightly newer Debian release, or is Devel::PatchPerl generally pretty reliable in that regard? 😅
(I guess maybe @atoomic is a better person to ask about this, given the relation to Devel::PPPort? 😄)

Edit: easier way to answer my own question was to try it out: #101 🤓

@atoomic
Copy link
Member Author

atoomic commented Apr 16, 2021

@tianon I see no reasons why we would not be able to rebuild Perl 5.8 and later on a more recent distribution.
Trying to build older versions might be more tricky but this is also doable.

@zakame
Copy link
Member

zakame commented Apr 19, 2021

Thanks for the discussions @tianon, @atoomic @oalders ! 🎉

I'd caution about the backfill rebuilds though, for exactly the same backwards compatibility reasoning - we don't know who's relying on what OS version they're using for a particular Perl version image. As @tianon's current PR stands we'll be building new stretch images for older perls but still keep the old jessie ones around (well, as long as Docker Hub lets them,) so we still need to give notice to users to switch over to the new images at their convenience (and for those who still want to keep using jessie for some reason, they're still free to do so.)

We'll also continue to document about updating needed OS dependencies like git and the compiler toolchain for CI or other cases.

@atoomic
Copy link
Member Author

atoomic commented Apr 19, 2021

One way to workaround that would be to use new tags for the updated images? Maybe using the distro (and version) name?
So we do not touch the old images and only provide up to date ones, so people can start using them?

@tianon
Copy link
Contributor

tianon commented Apr 22, 2021

Yeah, that's a great idea, IMO -- so we'd publish tags like perl:5.8-stretch and not touch perl:5.8

@atoomic
Copy link
Member Author

atoomic commented Apr 22, 2021

Not touching the existing images and using *-stretch or other seems a great idea

@zakame
Copy link
Member

zakame commented Apr 26, 2021

We already don't touch older images unless explicitly stated - all image updates are triggered by changes in library/perl, and we already specify which versions and variants to build.

@zakame zakame mentioned this issue May 6, 2021
zakame added a commit to zakame/docker-library-official-images that referenced this issue May 21, 2021
Ref Perl/docker-perl#104

This latest release of Perl now only builds against buster base, see
Perl/docker-perl#88.

Furthermore, some tags for older (unsupported) Perl versions are
requested for rebuild, see
Perl/docker-perl#100 - these tags will be
removed in a subsequent PR once done.
@zakame
Copy link
Member

zakame commented May 22, 2021

Rebuilds of old versions are now happening and should hit the Docker Hub soon 💪 Let me know if these work for you.

Thanks everyone here for the feedback!

zakame added a commit to zakame/docker-library-official-images that referenced this issue May 24, 2021
Images from Perl 5.8 to 5.28 are done rebuilding for
Perl/docker-perl#100.
@zakame
Copy link
Member

zakame commented May 24, 2021

Perl images from 5.8 up have now been rebuilt and available in the Docker Hub, with specific -stretch or -buster tags to pick up whatever new versions of git or other toolchain dependencies needed. Unqualified tags like perl:5.8 should still reference the old image if needed.

Thanks again everyone for the feedback! 🙇

briandfoy added a commit to briandfoy/github_workflows that referenced this issue Jun 17, 2024
yewtc added a commit to yewtc/www-shorten that referenced this issue Jul 1, 2024
The linux workflow has a workaround to deal with the fact that at the
momemt, the official perl images have an issue
see Perl/docker-perl#100

Not 5.40 for windows - yet

Try older ubuntu

Temp try buster versions of perl docker images

Back to latest ubuntu
yewtc added a commit to yewtc/www-shorten that referenced this issue Jul 1, 2024
The linux workflow has a workaround to deal with the fact that at the
momemt, the official perl images have an issue
see Perl/docker-perl#100
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants