Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lew Pitcher <lew.pitcher@digitalfreehold.ca>
Newsgroups: comp.os.linux.misc
Subject: Re: any way to completely disable Emacs eln-cache
Date: Fri, 5 Jul 2024 19:52:28 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 76
Message-ID: <v69its$3dons$1@dont-email.me>
References: <slrnv86vve.aen.spamtrap42@one.localnet>
	<p58elkxpuf.ln2@Telcontar.valinor>
	<slrnv89i5s.kr5.spamtrap42@one.localnet> <v63k03$26k9p$1@dont-email.me>
	<slrnv8anji.4een.candycanearter07@candydeb.host.invalid>
	<lem9mmFbns7U1@mid.individual.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 05 Jul 2024 21:52:29 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5f3f6b440d1d2cb4057d2c5c0ed7c5f3";
	logging-data="3597052"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/PUyrjBP6fp66dEWQoErpuU7UBei4V9es="
User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508
 git://git.gnome.org/pan2)
Cancel-Lock: sha1:bzs+MaRciH3uGTf8F9UhapZXnnM=
Bytes: 4316

On Thu, 04 Jul 2024 02:46:14 +0200, Carlos E. R. wrote:

> On 2024-07-03 16:30, candycanearter07 wrote:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote at 13:33 this Wednesday (GMT):
>>> On Wed, 03 Jul 2024 03:42:52 +0000, Robert Riches wrote:
>>>
>>>> On 2024-07-02, Carlos E.R. <robin_listas@es.invalid> wrote:
>>>>> On 2024-07-02 06:19, Robert Riches wrote:
>>>>>> Is there any practical way to completely disable Emacs' eln-cache
>>>>>> while using Devuan Daedalus binary packages, versions in the
>>>>>> 1.28.2 neighborhood?  Even better would be to entirely disable
>>>>>> native compilation.
>>>>>>
>>>>>> The cached files cause noise in Tripwire output and make messes
>>>>>> in directories Emacs should not be leaving messes in.  Recently,
>>>>>> I saw .el files being left in /tmp.
>>>>>
>>>>> emacs has all the right to leave any file it wishes in /tmp.
>>>>
>>>> Not on _MY_ machine, it doesn't.  Long-standing tradition says it
>>>> is a bug for a program to fail to clean up after itself in /tmp.
>>>
>>> Longer standing Unix tradition has a periodically-scheduled job
>>> (often known as "skulker" or "tmpwatch") that cleans out the various
>>> tmp directories (/tmp, /var/tmp, etc) of old, discarded temporary
>>> files.
>> 
>> 
>> Wait, really? I've been storing random files in /var/tmp..
> 
> Distributions have various policies and implementations of that.

True dat. The requirements of the Linux Filesystem Hierarchy Standard
(https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html) seem to
have been sidelined by many distros and developers. But, AFAICT, they
still are the recommended standards.

For /var/tmp, the FHS says:
  5.15. /var/tmp : Temporary files preserved between system reboots
  5.15.1. Purpose

  The /var/tmp directory is made available for programs that require
  temporary files or directories that are preserved between system
  reboots. Therefore, data stored in /var/tmp is more persistent than
  data in /tmp.

  Files and directories located in /var/tmp must not be deleted when
  the system is booted. Although data stored in /var/tmp is typically
  deleted in a site-specific manner, it is recommended that deletions
  occur at a less frequent interval than /tmp

As for /tmp, the FHS says:
  3.18. /tmp : Temporary files
  3.18.1. Purpose

  The /tmp directory must be made available for programs that require
  temporary files.

  Programs must not assume that any files or directories in /tmp are
  preserved between invocations of the program.

  Rationale
    IEEE standard POSIX.1-2008 lists requirements similar to the above
    section.

    Although data stored in /tmp may be deleted in a site-specific
    manner, it is recommended that files and directories located in
    /tmp be deleted whenever the system is booted.

    FHS added this recommendation on the basis of historical precedent
    and common practice, but did not make it a requirement because system
    administration is not within the scope of this standard.

-- 
Lew Pitcher
"In Skills We Trust"