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 wh
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 l
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 r
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
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?
N
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...)
>
An
6 matches
Mail list logo
