[Bug 62617] Honor SOURCE_DATE_EPOCH to allow reproducible builds

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=62617

--- Comment #2 from Jonas Witschel <di...@gmx.de> ---
Hi Jaikiran,

I would be very interested in reproducible build support in Apache Ant as well.

>(In reply to Jaikiran Pai from comment #1)
> I think, the proposed patch might not preserve the current behaviour. Since,
> right now, even if the SOURCE_DATE_EPOCH is set in the system where the
> build is run, the tstamp task will not use it and instead will use the
> current time. With this patch, the behaviour will change in such build
> files.
I don't see the point in preserving backwards compatibility in this case: if
SOURCE_DATE_EPOCH is set, the user explicitly expects time stamps to be set to
this fixed date instead of the current time as per the specification Julien
linked above. Using the current time instead is undesirable behaviour if the
environment variable is set, so I would consider the current behaviour a bug
that requires backwards-incompatible changes in order to be fixed.

Maybe it's a better idea to have an explicitly set attribute (a new
> attribute) on the task which will start honouring this environment variable?
> That way the default semantics of the attribute can continue to ignore this
> environment variable unless explicitly set to honour it. Some attribute like
> "useSourceDateEpoch".
That would defeat the goal of having reproducible support by default: every
projects needs to be aware of this attribute and explicitly set it, which will
not happen e.g. for legacy projects. All artifacts created by Apache Ant should
be reproducible out of the box if SOURCE_DATE_EPOCH is set.

> I believe you will need a epoch != null check here. In its current form,
> this will lead to a NPE on systems where the environment variable isn't set.
> Furthermore, I don't think the compareTo call is required. The "spec" that
> you pointed to, in the linked content, explicitly states that the value of
> such an environment variable MUST be an integer, so I think you can just try
> to use it as an Integer value. If you still want to check if the environment
> variable value is empty, then I think epoch.isEmpty() is a better API to use.
ACK on the review of the patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.