Skip to content
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

Make perllocal.pod files reproducible #279

Merged
merged 1 commit into from
Feb 3, 2017

Conversation

jmdh
Copy link
Contributor

@jmdh jmdh commented Aug 28, 2016

As per https://bugs.debian.org/834190 and https://bugs.debian.org/835815 this patch makes the perllocal.pod files generated by ExtUtils::MakeMaker be reproducible across builds. This patch is part of the Reproducible Builds0 project:

@Leont
Copy link
Member

Leont commented Aug 29, 2016

I'm not sure this is quite the right fix. I guess we want gmtime with SOURCE_DATE_EPOCH but localtime with time.

@jmdh
Copy link
Contributor Author

jmdh commented Aug 29, 2016

We have to use gmtime to make it reproducible across different environments, and changing the implicit timezone depending on whether it's overriden by an environment variable seems equally wrong. At least I assume that's the rationale behind this pattern; @lamby?

@lamby
Copy link

lamby commented Aug 29, 2016

No real rationate apart from most people don't care about the localtime/gmtime on a "day" level...

Feel free to split it like (untested):

if ($ENV{SOURCE_DATE_EPOCH}) {
    my $time = gmtime($ENV{SOURCE_DATE_EPOCH});
} else {
    my $time = localtime;
}
$pod = sprintf <<'POD', scalar($time), $type, $name, $name;

(etc.)

@dolmen
Copy link
Member

dolmen commented Aug 29, 2016

There are two things changed by this patch:

  • the timestamp used ($ENV{SOURCE_DATE_EPOCH} instead of system time)
  • how that timestamp is formated: localtime vs gmtime

I'm ok with the first one.

About the second one, how do you expect the build to be reproducible if the locale is not fixed in the build environment? Is the Debian reproducible build environment locale-dependent?

@jmdh
Copy link
Contributor Author

jmdh commented Aug 29, 2016

Yes, the recommendation is that builds use LC_ALL=C: https://reproducible-builds.org/docs/locales/

@lamby
Copy link

lamby commented Aug 29, 2016

is the Debian reproducible build environment locale-dependent

It is locale-dependent.

However, the gmtime vs localtime is not a locale issue, it's a timezone issue and is therefore orthogonal to any advice regarding LC_* environment variables.

@Leont
Copy link
Member

Leont commented Aug 29, 2016

Actually, the whole concept of perllocal seems rather non-reproducible to me

@bingos bingos merged commit d7341f0 into Perl-Toolchain-Gang:master Feb 3, 2017
@dolmen
Copy link
Member

dolmen commented Feb 7, 2017

Too bad this has been merged. A reproducible build should just disable perllocal generation (make pure_inst_perl).
This patch only brings Debian specific bits.

@lamby
Copy link

lamby commented Feb 8, 2017

@dolmen wrote:

A reproducible build should just disable perllocal generation

How would you suggest we do that reliably? Can we adjust this so that if SOURCE_DATE_EPOCH is set we just skip these bits "automatically" or are you saying we should call a different target (as well as export SOURCE_DATE_EPOCH for other time-related stuff)…? My gut/experience tells me the former would be more useful/practical.

@dolmen
Copy link
Member

dolmen commented Feb 9, 2017

How would you suggest we do that reliably?

Written above: make pure_inst_perl

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

Successfully merging this pull request may close these issues.

None yet

5 participants