Re: [gnu-prog-discuss] Automake dist reproducibility

[Ludovic Courtès]

Pádraig Brady  skribis:

> On 22/12/15 17:00, Mike Gerwitz wrote:
>> There is ongoing discussion about reproducible builds within GNU.  I'm
>> having trouble figuring out the best approach for deterministic
>> distribution archives using Automake.
>
> I've not thought much about this, but I'm
> wondering about how useful deterministic tarballs are?
>
> The main thrust of reproducible builds is to verify what's
> running on the system, and there are so many variables
> between the tarball and build, that I'm not sure it's
> worth worrying about non determinism in the intermediate steps?
>
> Perhaps the main focus for tarballs should just to
> ensure they're properly signed.

You’re right that deterministic tarballs are not the immediate concern
of reproducible builds; usually, we focus on binaries.

However, if running ‘make dist’ at a given commit of a project leads to
exactly one tarball, then people can verify the tarball against the VCS
commit.  This is especially interesting when people sign commits/tags.
We could authenticate code with much finer grain.

This also reduces incentives to attack the person that runs ‘make dist’
and signs the result since anyone could independently check the tarball.

Basically same motivation as with reproducible builds, but one level
higher.

Ludo’.

Re: Could automake-generated Makefiles required GNU make?

[Ludovic Courtès]

Hi Stefano,

Stefano Lattarini  skribis:

> On Tuesday 22 November 2011, Ludovic Courtès wrote:

[...]

>> It seems to me that this proposal would fill a niche between current
>> Automake and Quagmire.
>> 
>> IMO that niche may be small.  One of Automake’s strengths is to support
>> multiple make implementations.  If you’re going to require GNU make, why
>> not take Quagmire’s approach, so you really get to benefit more from
>> GNU make features?
>> 
> Basically, because I want something that work *from day zero*.

Well Quagmire already “works”, right?  :-)

>   <http://lists.gnu.org/archive/html/automake/2011-01/msg00077.html>

I’m not convinced by these arguments.  I think Quagmire could reasonably
be taken over by other hackers (it’s not that complex, after all), and
could be attractive to GNU hackers because it’s so close to Automake–if
only the “social” part would work well.  But hey, who knows?

Thanks,
Ludo’.

Re: Could automake-generated Makefiles required GNU make?

[Ludovic Courtès]

Hi,

Reuben Thomas  skribis:

> Or you could use Lua (www.lua.org)

Or even GNU Guile:

  - embedded in GNU Make:
.

  - on its own: .

Thanks,
Ludo’.

Re: Could automake-generated Makefiles required GNU make?

[Ludovic Courtès]

Hi Stefano,

Stefano Lattarini  skribis:

> Here is my tentative plan to act on the proposal:
>
>   1. We start requiring GNU make in an "experimental" automake 2.0
>  development line (which might, and will, break whathever
>  backward-compatibility gets in its way).
>   2. Concurrently, we continue to support the more portable (and
>  tested, and used-in-the-real-world) 1.x line, with bugfixes
>  at least (and probably also with addition of new not-too-big
>  features).

It seems to me that this proposal would fill a niche between current
Automake and Quagmire.

IMO that niche may be small.  One of Automake’s strengths is to support
multiple make implementations.  If you’re going to require GNU make, why
not take Quagmire’s approach, so you really get to benefit more from
GNU make features?

Thanks,
Ludo’.

Re: easier nonrecursive makefiles

[Ludovic Courtès]

Hi!

Ralf Wildenhues  writes:

> Hmm, or do both:
>   foo_SOURCES += %ADDPREFIX%(%AM_PREFIX%,
>  file1.c file2.c ...)
>
> in sub/fragment.am, and with
>   include $(srcdir)/sub/fragment.am
>
> would expand (at automake run time) to
>   foo_SOURCES += sub/file1.c sub/file2.c

I second this proposal, but I may well be overlooking some of the
implications...

Thanks,
Ludo’.


pgpp6XEpxiZM8.pgp
Description: PGP signature