Hence, I am not really looking for philosophical discussions or lists
of personal preferences or hypotheticals, but for facts: what would
break where, and how to fix it?
Luca Boccassi <bluca@debian.org> writes:
Hence, I am not really looking for philosophical discussions or lists
of personal preferences or hypotheticals, but for facts: what would
break where, and how to fix it?
cleaning /tmp or /var/tmp: users may lose files if they dont realise a
directory tmp can be cleaned without a reboot. something in /var/tmp
that's been in there for 35 days before an upgrade might be deleted
before the user reads the NEWS.Debian email, meaning they have no
chance to react). Maybe you could postpone the very first deletion
until after the next reboot?
using a tmpfs: is there a risk of losing unrelated data due to more
frequent OOM killing random other programmes due to /tmp using all the
memory? is there a case to only use a tmpfs if the system has
"enough" memory?
On Mon, 6 May 2024 at 15:42, Richard Lewis <richard.lewis.debian@googlemail.com> wrote:
Luca Boccassi <bluca@debian.org> writes:
Hence, I am not really looking for philosophical discussions or lists
of personal preferences or hypotheticals, but for facts: what would
break where, and how to fix it?
cleaning /tmp or /var/tmp: users may lose files if they dont realise a
directory tmp can be cleaned without a reboot. something in /var/tmp
that's been in there for 35 days before an upgrade might be deleted
before the user reads the NEWS.Debian email, meaning they have no
chance to react). Maybe you could postpone the very first deletion
until after the next reboot?
using a tmpfs: is there a risk of losing unrelated data due to more
frequent OOM killing random other programmes due to /tmp using all the
memory? is there a case to only use a tmpfs if the system has
"enough" memory?
Again, those are all hypotheticals, and one can construct similarly
contrived thought exercises for most possible permutations of most configurations, and the answer is always the same: customize the configuration accordingly. Hence, not relevant right now.
What is relevant is: which packages, if any, or which DSA-owned
systems, if any, are actually affected and how?
Hence, I am not really looking for philosophical discussions or lists
of personal preferences or hypotheticals, but for facts: what would
break where, and how to fix it?
Luca Boccassi <bluca@debian.org> writes:
Hence, I am not really looking for philosophical discussions or lists
of personal preferences or hypotheticals, but for facts: what would
break where, and how to fix it?
- tmux stores sockets in /tmp/tmux-$UID
- I think screen might use /tmp/screens
I suppose if you detached for a long time you might find yourself unable
to reattach.
I think you can change the location of these.
Richard Lewis <richard.lewis.debian@googlemail.com> wrote:
- tmux stores sockets in /tmp/tmux-$UID
- I think screen might use /tmp/screens
I suppose if you detached for a long time you might find yourself
unable to reattach.
I think you can change the location of these.
And those are useful only as long as screen/tmux are still running,
right (I don't really use either that much)? If so, a flock is the right solution for these
"Luca" == Luca Boccassi <bluca@debian.org> writes:
qwhat would
break where, and how to fix it?
Luca Boccassi <bluca@debian.org> writes:
what would break where, and how to fix it?
Another one for you to investigate: I believe apt source and 'apt-get
source' download and extract things into /tmp, as in the mmdebootstap
example mentioned by someone else, this will create "old" files that
could immediately be flagged for deletion causing surprises.
(People restoring from backups might also find this an issue)
Richard Lewis <richard.lewis.debian@googlemail.com> writes:
Luca Boccassi <bluca@debian.org> writes:
what would break where, and how to fix it?
Another one for you to investigate: I believe apt source and 'apt-get source' download and extract things into /tmp, as in the mmdebootstap example mentioned by someone else, this will create "old" files that
could immediately be flagged for deletion causing surprises.
(People restoring from backups might also find this an issue)
systemd-tmpfiles respects atime and ctime by default, not just mtime, so I think this would only be a problem on file systems that didn't support
those attributes. atime is often turned off, but I believe support for
ctime is fairly universal among the likely file systems for /var/tmp, and
I believe tmpfs supports all three. (I'm not 100% sure, though, so please correct me if I'm wrong.)
"Luca" == Luca Boccassi <bluca@debian.org> writes:
Luca> On Mon, 6 May 2024 at 15:42, Richard Lewis
Luca> <richard.lewis.debian@googlemail.com> wrote:
>>
>> Luca Boccassi <bluca@debian.org> writes:
>>
>> > Hence, I am not really looking for philosophical discussions or
>> lists > of personal preferences or hypotheticals, but for facts:
>> what would > break where, and how to fix it?
ssh-agent appears to default to creating a socket under /tmp.
I think respecting $XDG_RUNTIME_DIR would be better.
/etc/X11/Xsession.d/90x11-common_ssh-agent also doesn't override where
the socket ends up.
I definitely think for session scripts like that $XDG_RUNTIME_DIR would
be better.
gnome-keyring's ssh-agent handles this better, although last time I
checked, it did not support pkcs11, so I could not use it with PIV
cards.
(Other parts of gnome-keyring do support pkcs11).
On May 28, Andreas Metzler <ametzler@bebt.de> wrote:
I think it is bad choice to deliberately have different behavior forI strongly disagree: it is a bad choice to change on upgrades a default
freshly installed and upgraded systems. Offering upgrades has always
been one of the major selling points of Debian, and imho this
implicitely includes that you do not get a worse or second class Debian
installation when you upgrade it than if you installed from scratch.
which may cause data loss.
On Wed, 29 May 2024 00:44:29 +0200, Marco d'Itri <md@Linux.IT> wrote:
On May 28, Andreas Metzler <ametzler@bebt.de> wrote:
I think it is bad choice to deliberately have different behavior forI strongly disagree: it is a bad choice to change on upgrades a default >which may cause data loss.
freshly installed and upgraded systems. Offering upgrades has always
been one of the major selling points of Debian, and imho this
implicitely includes that you do not get a worse or second class Debian
installation when you upgrade it than if you installed from scratch.
I also think that a change of this kind is release notes material. A
system having been updated for two decades is bound to carry some
cruft.
- two paragraphs have been provided for the release notes ticket
On 28.05.2024 ÖS 8:16, Andreas Metzler wrote:
On 2024-05-28 Luca Boccassi <bluca-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> wrote:
[...]
- existing installations pre-trixie will get an orphaned tmpfiles.d in /etc/ that keeps the existing behaviour unchanged (no cleanup of /var/tmp)[...]
Hello,
I think it is bad choice to deliberately have different behavior for freshly installed and upgraded systems. Offering upgrades has always
been one of the major selling points of Debian, and imho this
implicitely includes that you do not get a worse or second class Debian installation when you upgrade it than if you installed from scratch.
cu Andreas
I'll kindly disagree here.
I'd rather not have to go back to every system^^^^^^^^^^^^^^^^^^^^^
and make sure that they all behave the way I want after doing a periodic,
completely boring "apt-get upgrade".
On 29 May 2024, at 17:33, Marvin Renich <mrvn@renich.org> wrote:Sorry, I thought that the sentence was self explanatory. Using English as a second language has its peculiarities. Let me explain.
* Hakan Bayındır <hakan@bayindir.org> [240529 07:51]:
On 28.05.2024 ÖS 8:16, Andreas Metzler wrote:
On 2024-05-28 Luca Boccassi <bluca-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> wrote:
[...]
- existing installations pre-trixie will get an orphaned tmpfiles.d in >>>> /etc/ that keeps the existing behaviour unchanged (no cleanup of[...]
/var/tmp)
Hello,
I think it is bad choice to deliberately have different behavior for
freshly installed and upgraded systems. Offering upgrades has always
been one of the major selling points of Debian, and imho this
implicitely includes that you do not get a worse or second class Debian
installation when you upgrade it than if you installed from scratch.
cu Andreas
I'll kindly disagree here.
While I agree with Andreas that having the same behavior for upgraded
systems and new installations is generally better, I agree with you that
in this specific case it is not the better choice.
I'd rather not have to go back to every system^^^^^^^^^^^^^^^^^^^^^
and make sure that they all behave the way I want after doing a periodic,
completely boring "apt-get upgrade".
You haven't specified what behavior you want. Is it the existing
behavior or the new behavior? This thread is exactly about choosing
between the two, and possibly between different behavior for new and
existing systems.
There are four combinations of old/new behavior and upgrading/new installation. Eliminating the obviously bad combination, we are left
with three:
A. Keep old behavior for both upgrading and new installations.
B. Keep old behavior for upgrading, use new behavior for new installations. C. Apply new behavior for both.
The new behavior is preferable for many use cases, but the old behavior
is not a "BUG" that must be fixed. Debian has had the old behavior for
a very long time.
A number of people have spoken up on this list saying that they are
relying on the old behavior, and that changing to the new behavior could potentially cause serious data loss.
Some people have stated an opinion that keeping upgraded systems in sync
with the behavior of new installations is desirable.
So to choose between A, B, and C, we must rank the following:
X. desirability of new behavior
Y. preventing data loss for an unspecified, but non-zero, number of
existing systems
Z. desirability of having upgraded systems match new installations.
Both X and Z are primarily opinions with some (non-overwhelming)
technical merit to each.
Sufficient technical arguments have been provided on this meta-thread to support that Y is highly important and also more important than both X
and Z. This means that choice C fails.
If Z were more important than X, then the order of importance would
become Y, then Z, then X, which would make choice A the winner.
However, there have been no technical arguments whatsoever that Z is
more important than either of X or Y, only a few personal opinions.
And, from the discussion, the consensus appears to be that X is more important than Z, so the order is Y, then X, then Z.
This gives us choice B as the wi
nner.
It also looks like Luca Boccassi has already made the changes to effect choice B. Thank you, Luca!
,,,Marvin
I'll kindly disagree here. I'd rather not have to go back to every
system and make sure that they all behave the way I want after doing a >periodic, completely boring "apt-get upgrade".
On 30 May 2024, at 09:15, Marc Haber <mh+debian-devel@zugschlus.de> wrote:
On Wed, 29 May 2024 14:35:27 +0300, Hakan Bay?nd?r
<hakan@bayindir.org> wrote:
I'll kindly disagree here. I'd rather not have to go back to every
system and make sure that they all behave the way I want after doing a
periodic, completely boring "apt-get upgrade".
This change is likely to come to the majority of our installations
("stable") with a release upgrade, which is never boring, but one of
the most exciting things that can happen to a Debian stable system.
People doing this responsibly read the release notes before beginning,
and those release notes have in the past contained things that needed
doing manually in the process such as the well-known "please upgrade
kernel first and reboot" during one udev/systemd upgrade.
Ubuntu seems to have put the release notes in an automatism disguise
called do-release-upgrade which probably changes from release to
release regarding what specialty is in the store for this update. We
don't have that, we ask our users to read the release notes.
Greetings
Marc
-- ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 161:32:37 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,500 |