Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

["Ludovic Courtès" <ludo@gnu.org>]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

[...]

>>> Changing all pre-existing packages, maybe.  But doing this for new
>>> packages (reducing review effort) and perhaps when a package is updated
>>> (for purity) should be feasible I think?  Then gradually things would
>>> improve and eventually(TM) doing the switch in the bootstrap phase may
>>> become feasible ...
>>
>> Yes, we could do that as a first step (in fact it’s already happening as
>> some projects no longer distribute tarballs).
>>
>> What do maintainers think of that policy?
>
> No strong opinion, but I agree that having a complete development
> environment capable of building from the bare sources (e.g. a git tree)
> is useful in general.  On the other hand, using tarballs is often more
> efficient and practical (it's made to be built by downstream users,
> rather than by developers, so it includes everything needed).  Release
> tarballs are also often signed by the projects, which is neat.

Right, authentication can be a good reason to keep using tarballs.

Projects that publish signed tarballs are likely to use signed tags as
well though.  We just need to update ‘guix refresh’ to handle signed
tags.

(Another argument, this time against tarballs, is archival, though that
part if now partly addressed thanks to Disarchive.)

> So perhaps we can leave some flexibility there and not make it a hard
> rule, but a case of best judgment?

Yeah.

Thanks,
Ludo’.