[arch-general] No login after update

[Yaro Kasear]

On Wed, Aug 19, 2020 at 3:32 PM Yaro Kasear <yaro at marupa.net> wrote:

> 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
>

Correcting myself on a badly worded sentence.  "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."

What I meant to say was, "It will drop a pacnew regardless of differences
between packages if it sees a difference between what's in the new package
and what's installed regardless of if the file is needed."

Sorry about that.

Yaro