-
Notifications
You must be signed in to change notification settings - Fork 51
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
Comments
Would be nice to address the issue at this level. |
For the images on Docker Hub (https://hub.docker.com/_/perl), only the tags listed in the official-images (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 FYI, the $ 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 |
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. |
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. :) |
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 |
Another option would be a one-time rebuild of these older versions (add them to I'm curious though, what's the use case for testing against unsupported/EOL versions of Perl? |
A typical use case is to publish a distribution to CPAN... and using GitHub workflow to check if regressions are introduced |
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 |
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. |
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 |
This would be awesome! |
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 Edit: easier way to answer my own question was to try it out: #101 🤓 |
@tianon I see no reasons why we would not be able to rebuild Perl 5.8 and later on a more recent distribution. |
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 We'll also continue to document about updating needed OS dependencies like git and the compiler toolchain for CI or other cases. |
One way to workaround that would be to use new tags for the updated images? Maybe using the distro (and version) name? |
Yeah, that's a great idea, IMO -- so we'd publish tags like |
Not touching the existing images and using |
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. |
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.
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! |
Images from Perl 5.8 to 5.28 are done rebuilding for Perl/docker-perl#100.
Perl images from 5.8 up have now been rebuilt and available in the Docker Hub, with specific Thanks again everyone for the feedback! 🙇 |
…Perl/docker-perl#100, briandfoy/cpan-audit#58) Co-authored-by: Zak B. Elep <[email protected]>
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
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
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
copy: @FGasper / @oalders
discussed here Perl/docker-perl-tester#18
The text was updated successfully, but these errors were encountered: