Arch devs,
I'm left wondering what purpose was served by not providing a pre-update note or post-install restoration of any existing .pacsave found? The new sample wpa_supplicant.conf is in /usr/share/doc/wpa_supplicant/wpa_supplicant.conf.
If this was simply due to a pacman default action where /etc/wpa_supplicant/wpa_supplicant.conf was removed upstream, could a one-off 'post-install' script check for the original .pacsave and restore it?
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)
Food for thought for the packagers. In these cases, I would think we would either want some type of pre-update note on archlinux.org (like for ttf-dejavu) or some post install restoration of the original config. I'll reiterate, at least for the cases where the packager 'knows' a broken config will result.
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...)
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,
On 18 December 2016 at 21:32, Leonid Isaev leonid.isaev@jila.colorado.edu 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
On Sun, Dec 18, 2016 at 09:40:29PM +0100, Maarten de Vries wrote:
On 18 December 2016 at 21:32, Leonid Isaev leonid.isaev@jila.colorado.edu 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?
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.
On Sun, 18 Dec 2016 14:25:00 -0600 "David C. Rankin" drankinatty@suddenlinkmail.com 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".
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
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
arch-general@lists.archlinux.org