[arch-general] No login after update

[Yaro Kasear]

On Wed, Aug 19, 2020 at 3:17 PM Archange <archange at archlinux.org> wrote:

>
> Le 20/08/2020 à 00:04, Yaro Kasear a écrit :
> > On 8/19/20 2:56 PM, Yaro Kasear wrote:
> >> On 8/19/20 2:48 PM, Giancarlo Razzolini via arch-general wrote:
> >>> Em agosto 19, 2020 16:37 Yaro Kasear escreveu:
> >>>> I've always questioned the wisdom of dropping a .pacnew just when the
> >>>> file is different from the default. There's really no reason for it
> >>>> considering any changes you made were deliberate and presumably
> thought
> >>>> out. The end result is pacman cluttering /etc with a default
> >>>> configuration file whose only reason for existing is to, if it's used,
> >>>> clear settings. Why?
> >>>>
> >>> The .pacnew is there to indicate that something new exists, or that
> >>> you changed
> >>> something. Most of the time you can remove .pacnew files, but not
> >>> always. Also,
> >>> it's only "cluttering" /etc (and /boot, btw), if you don't handle them.
> >>>
> >>>> What pacman SHOULD do is compare /etc files between package versions
> and
> >>>> see if there's a change BETWEEN DEFAULTS. *Then* there's an actual
> >>>> reason to need a new default config file for the user to examine
> because
> >>>> then there's an actual indicator some meaningful change in default
> >>>> configuration or how the package handles configs happened.
> >>>>
> >>> That's way beyond the scope of a package manager, and also, there's no
> >>> way
> >>> to tell what "DEFAULTS" (why caps?) should be.
> >> Caps for emphasis is all.
> >>>> All most pacnew files wind up doing is sitting there for thirty
> seconds
> >>>> before being deleted without anyone even opening them because they're
> >>>> literally just what the file was before the user ALREADY changed it
> >>>> before... because it's utterly useless to get a default config file
> when
> >>>> you've intentionally changed it and there's nothing in the new version
> >>>> of the package that calls for an examination of the defaults.
> >>>>
> >>> I don't know why you said that .pacnew sits for thirty seconds before
> >>> being
> >>> deleted. Are you using a hook that does this? Because nothing handles
> >>> them
> >>> automatically, that's the user's job. There are tools to aid in doing
> >>> that,
> >>> but in the end the user should know what to apply, and what to discard.
> >> I wasn't being literal about thirty seconds. Exaggerating.
> >>> Regards,
> >>> Giancarlo Razzolini
> >> Yaro
> >>
> >>
> > Oh, also:
> >
> > "That's way beyond the scope of a package manager, and also, there's no
> > way to tell what "DEFAULTS" (why caps?) should be."
> >
> > Yes there is. The defaults are literally what's in the config file in
> > the archive and not on the filesystem. How would that not be a way to
> > determine default settings?
> >
> > I'm not suggesting the package manager would have to understand the
> > settings, but it would be able to tell if the contents of that file are
> > different from another version. (Which it obviously does already,
> > otherwise it wouldn't know to make a pacnew file.)
> >
> > I can't imagine it'd be that difficult for pacman to compare checksums
> > between files in /etc or /boot between versions of a package (If a
> > previous version is available.) and what's on /etc and determine if it
> > really needs to bother putting a pacnew file on the filesystem that
> > doesn't need to be there. It's already doing some sort of check between
> > what's in the package and what's on the filesystem already.
> >
> > Yaro
>
> pacman does this: if the *packaged file* changed between the installed
> version and the new one, and the *installed file* is different from the
> *packaged file*, then drop a .pacnew.
>
> I’m not sure what you want more…
>
> Bruno/Archange
>

But that is not what I am talking about.

I'm discussing what is essentially three configuration files here:

- The config in old-package.
- The config in new-package.
- The config on the filesystem.

I already know pacman compares new-package and filesystem config. It does
NOT do any check between old-package and new-package.

What I'm saying is a pacnew seems unnecessary if the file between
old-package and new-package are the same, because it means there's
absolutely nothing of use to the user there, as either the user's made
changes themselves and thus that file from the package is just going to be
settings they don't want, or it's never been changed, in which case
extracting the file's entirely redundant as it's literally still the same
file. Pacman wouldn't do a pacnew in that case as it's implemented so
that's beside the point.

I'm not talking about the existing new-package to filesystem version
checks, I'm talking about a case where if a package upgrade doesn't bring a
new configuration change, the pacnew's just a waste of time and space
(Albeit tiny amounts of space.) for the user.

I'm suggesting pacman check not just between installed and new-package
versions of the config but, if the old-package is still in the cache, take
a moment to see if the old-package and new-package version of the config
file are different, to stop pacman from dropping a file that will literally
just need to be deleted.

A pacnew is only really useful when the config file changes between
versions *because* a change in the file between old-package and new-package
could be because of some upstream change that the user might need to
address. But when it's just the same default configuration they already
changed from, a pacnew's pointless.

Unless I missed something, pacman drops a pacnew regardless if there's a
difference between new-package and what's on the filesystem and doesn't
care if the pacnew is really needed.

Yaro