Re: [arch-general] Why was wpa_supplicant.conf renamed wpa_supplicant.conf.pacsav??

[Bennett Piater]

> Other than that, I don't like gentoo's way of dealing with this
> problems other than the fact they ship tooling to actually deal with
> the 3-way merge pacman expects from the user. I'd welcome suggestions
> on this and actually was not smart enough up to now to somehow have a
> script dig up the old version's unmodified configuration file (to be
> used in said merge). I know there's the pacman cache, but pacman
> itself doesn't seem to need that to know there's a merge going on.
> There's definitely potential in doing this that might benefit
> everyone, please approach me for a follow-up.

What's wrong with pacdiff(1)?
That will happily call vimdiff, or meld, or whatever else you want in
the background.

Cheers,
Bennett

-- 
GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Why was wpa_supplicant.conf renamed wpa_supplicant.conf.pacsav??

[Martin Kühne via arch-general]

Please, never ever seriously consider making pacman surprising in any
way resembling to what has been unsuccessfully proposed.
Does the pacman wiki suggest running the following line after updates yet?

find /etc /opt /usr /var -regextype egrep -regex '\*.pac(new|save)'

A section describing the results of this might also hint to why you
probably don't need to update your mirrorlist every time, why using
rankmirrors is probably not a good idea and that critical stuff like
ssh configuration should be dealt with immediately in the cloud,
otherwise users might be locked out.
Personally I also ongoingly ignore
/etc/libvirt/qemu/networks/default.xml.pacnew because it depends on
network device name. I think at some point I might have to discuss
this with the respective package maintainer.

Other than that, I don't like gentoo's way of dealing with this
problems other than the fact they ship tooling to actually deal with
the 3-way merge pacman expects from the user. I'd welcome suggestions
on this and actually was not smart enough up to now to somehow have a
script dig up the old version's unmodified configuration file (to be
used in said merge). I know there's the pacman cache, but pacman
itself doesn't seem to need that to know there's a merge going on.
There's definitely potential in doing this that might benefit
everyone, please approach me for a follow-up.

cheers!
mar77i

Re: [arch-general] Why was wpa_supplicant.conf renamed wpa_supplicant.conf.pacsav??

[Doug Newgard]

On Sun, 18 Dec 2016 14:25:00 -0600
"David C. Rankin"  wrote:

>   Here, anyone relying on remote access via wpa_supplicant is left dead in the
> water unless they catch the comment as it scrolls by before rebooting. (yes
> they should review the comments, but with human nature what it is...)
> 

Another case of "ignore what pacman tells you at your own peril".

Re: [arch-general] Why was wpa_supplicant.conf renamed wpa_supplicant.conf.pacsav??

[Eli Schwartz via arch-general]

On 12/18/2016 04:16 PM, Leonid Isaev wrote:
> Update messages are hard to see if they scroll past quickly, or when updating
> via scripts. On the other hand, pacman.log contains "warning:" lines that show
> which files were renamed. And why do you believe that logs are only useful
> post-mortem?

Now, *there's* a simple fix. Don't do automatic updates via scripts.

Part of Arch's design is that users should keep an eye on what the
package manager does and heed any messages it gives. If the output
scrolls past quickly, a post-install message would get lost too, and
let's not even get into how bad an idea scripted updates are!

There is no change needed. This particular file is no different from all
the many many many other files and pacman messages in general that have
been *the responsibility of the user* to read end-of-story, since time
immemorial.

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Why was wpa_supplicant.conf renamed wpa_supplicant.conf.pacsav??

[Leonid Isaev]

On Sun, Dec 18, 2016 at 09:40:29PM +0100, Maarten de Vries wrote:
> On 18 December 2016 at 21:32, Leonid Isaev 
> wrote:
> 
> > On Sun, Dec 18, 2016 at 02:25:00PM -0600, David C. Rankin wrote:
> > >   I know this is small-potatoes stuff, but I just wonder if in these
> > > instances, it may not be better to either provide pre-update notice or
> > do a
> > > post-install script rather than relying on a post update action by the
> > user?
> > > At least in the cases where you know up-front that existing
> > functionality will
> > > be disabled by the upgrade. (which was apparent from the comment)
> >
> > Hmm, what about reading /var/log/pacman.log?
> >
> >
> ​A log is great for figuring out what went happened after something broke,
> but it shouldn't have to be part of a normal upgrade procedure in my
> opinion. Personally I do think the provided message was enough though.

Update messages are hard to see if they scroll past quickly, or when updating
via scripts. On the other hand, pacman.log contains "warning:" lines that show
which files were renamed. And why do you believe that logs are only useful
post-mortem?

-- 
Leonid Isaev

Re: [arch-general] Why was wpa_supplicant.conf renamed wpa_supplicant.conf.pacsav??

[Maarten de Vries via arch-general]

On 18 December 2016 at 21:32, Leonid Isaev 
wrote:

> On Sun, Dec 18, 2016 at 02:25:00PM -0600, David C. Rankin wrote:
> >   I know this is small-potatoes stuff, but I just wonder if in these
> > instances, it may not be better to either provide pre-update notice or
> do a
> > post-install script rather than relying on a post update action by the
> user?
> > At least in the cases where you know up-front that existing
> functionality will
> > be disabled by the upgrade. (which was apparent from the comment)
>
> Hmm, what about reading /var/log/pacman.log?
>
>
​A log is great for figuring out what went happened after something broke,
but it shouldn't have to be part of a normal upgrade procedure in my
opinion. Personally I do think the provided message was enough though.

I'd be a bit scared if package maintainers would add scripts to
automatically rename files. This case might have been safe, but in general
it is impossible for package maintainers to predict what users may have
done to their system and how post-upgrade scripts would interact with that.
I'm very happy that Arch lets the user (the one who knows the system best)
deal with this type of problem.

-- Maarten

Re: [arch-general] Why was wpa_supplicant.conf renamed wpa_supplicant.conf.pacsav??

[Leonid Isaev]

On Sun, Dec 18, 2016 at 02:25:00PM -0600, David C. Rankin wrote:
>   I know this is small-potatoes stuff, but I just wonder if in these
> instances, it may not be better to either provide pre-update notice or do a
> post-install script rather than relying on a post update action by the user?
> At least in the cases where you know up-front that existing functionality will
> be disabled by the upgrade. (which was apparent from the comment)

Hmm, what about reading /var/log/pacman.log?

Cheers,
-- 
Leonid Isaev