GNU bug report logs - #22213
24.5; please allow specification or elimination of timestamp in autoloads

Previous Next

Package: emacs;

Reported by: David Bremner <david <at> tethera.net>

Date: Sat, 19 Dec 2015 18:56:01 UTC

Severity: normal

Found in version 24.5

Fixed in version 26.1

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: David Bremner <david <at> tethera.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 22213 <at> debbugs.gnu.org
Subject: bug#22213: 24.5; please allow specification or elimination of timestamp in autoloads
Date: Mon, 21 Dec 2015 08:28:12 -0400
[Message part 1 (text/plain, inline)]
Glenn Morris <rgm <at> gnu.org> writes:

> David Bremner wrote:
>
>> It changes the problem to one of managing timestamps of files. This is
>> probably easier than the current situation, but not completely trivial,
>> since e.g. both git checkout and build systems that copy files will
>> modify timestamps.
>
> Point taken about VCS checkouts. Is that a case you need to deal with?

It seems pretty common for multi-file packages to have some kind of
staging process (e.g. "make elpa") in their build process (at least
company-mode, circe, magit, and projectile all do). This means the
production of tarball itself has timestamps based the VCS checkout.

Of course, in this case one could push the responsibility back onto the
package authors, but toolchain fixes seem better if possible (where
emacs is the toolchain here).

> I was thinking of rebuilding a binary package from a given
> source tarfile. But surely a build system must preserve source file
> timestamps, for the sake of make?

They only need to be preserved in a limited way to satisfy make; for
example in the staging process above, the copied files are not examined
by make after copying.

> 1) Store no timestamp in the loaddefs file, and use the modtime of the
> loaddefs file instead. In fact, I'm not sure why we don't just do it
> this way...

[snips]

> I'm guessing you don't care about in-place updating of a pre-existing
> loaddefs after modifying the inputs, so 1) would be fine?

Right, personally I think the installed files, including any generated
loaddefs (I'm guessing you're using loaddefs in a generic sense,
independent of the setting of GENERATED-AUTOLOADS-FILE?), should be
immutable.

Stefan's comment about stripping comments from the loaddefs files as
part of the install process is intriguing. Am I correct in thinking this
is pretty much equivalent to your option #1, in that the ";;;###"
section is only used for updating the loaddefs file?

Cheers,

David
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 8 years and 297 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.