Perl / Perl/docker-perl

Do we need generate.pl to wipe/recreate the download dir every time?

Open
#197 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Dockerfile
Stars
129
Forks
54
Avg merge
21m
Merged PRs (30d)
2

Description

I'm regenerating the Dockerfiles and I noticed it takes ages. 10 years ago it was added via 5150798c. I'm not 100% if we still need this tear-down, tear-up strategy.

Perhaps we can add some kind of flag to generate.pl to keep the old behaviour, but this would speed up regenerations.

  {
    my $dir = "$downloads/perl-$release->{version}";
    qx{rm -fR $dir};
    mkdir $dir or die "Couldn't create $dir";
    qx{
      tar -C "$downloads" -xf $dir.tar.gz &&\
      cd $dir &&\
      chown -R \$(id -u):\$(id -g) . &&\
      git init &&\
      git add . &&\
      git commit -m tmp
    };
    die "Couldn't create a temp git repo for $release->{version}" if $? != 0;
    Devel::PatchPerl->patch_source($release->{version}, $dir);
    $patch = qx{
      cd $dir && git -c 'diff.mnemonicprefix=false' diff
    };
    die "Couldn't create a Devel::PatchPerl patch for $release->{version}" if $? != 0;
  }

I often see cat *.patch errors in the logs when an image is build, so the slowdown seems not justifiable.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the directory teardown and temporary Git repository logic in generate.pl, then reproduce the slow Dockerfile regeneration and inspect the reported cat *.patch errors. Done means the need to wipe and recreate the download directory is established and any changed behavior preserves a way to retain the old behavior if required.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, perl
Domain
build-system
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.