On Wed, Aug 19, 2020 at 3:32 PM Yaro Kasear <yaro@xxxxxxxxxx> wrote: > On Wed, Aug 19, 2020 at 3:17 PM Archange <archange@xxxxxxxxxxxxx> 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
