Feature request: dedicated update-manager


#61

Pamac already shows those details in the details tab. I’m not sure if bumping stderr to the popup would ease the troubleshooting for anyone.


#62

I feel like it would be more straightforward. The details tab is basically in what is in pacman log.


#63

I think precautions at other ends (brtfs, timeshift, etc.) are nice and well, but are not functionally related to the question of how to enable the user to perform a sane update every time.

I get that there is no THE one perfect update command? Maybe there is one that is usually safer than the GUI methods?

I believe that we will experience update hiccups in stable in future due to the following reasons:

  1. the testing crew is EXPERIENCED (and yes, it should be) and likely chooses update routines that avoid (in their view unnecessary) breakages. Or how many testing users reading this thread regularly perform updates with the GUI package managers?
  2. Regular users (i.e. many of those using Manjaro happily and not hanging around in the forum) will continue to use the easy and nice GUI tools and have their occasional BOOM experience, because how should they have been aware of it when Manjaro runs for months and months totally fine like that?

So to raise awareness, the idea is to provide means that notify users of updates, which means include suggesting for them to use a recommended update method for this update.

The questions are: should this be done by EVERY update? If this should only be done for critical updates then who declares them critical and by which means are these updates tagged critical?

I tend to do it for EACH update, since the assessment of whether an update is critical or not may be difficult and/or error prone. OR one could simply declare an update critical if it includes one of the “core” packages (e.g. those included in Manjaro architect?).

One idea to advance the implementation is to think about a decision tree: what packages/kind of update would require which preferred pacman command (-Syu, -Syyu, -Syyuu, etc.), where (terminal or tty)? E.g. if Xorg packages are to be updated would it be better to do them in level 3 or a tty? If a package downgrade is included then do -Syyuu. If kernel or other core packages are concerned, then do …, etc.


#64

Well, there are a few categories of “critical” updates:

  1. update requires manual intervention and this is known and announced beforehand
  2. update includes kernel updates, in which case it is critical that the update is not interrupted before it is finished.
  3. update to kernel, networkmanager, libinput, graphics drivers, xorg or systemd might introduce breaking changes. The problem is specific to single system and might require a temporary downgrade. Only ways to prepare for these situations are back ups and live system. They cannot be detected prior to the update.

#65

Honestly, these kind of users then deserve what they get. The point is not to be idiot proof, but to raise user awareness. I think the majority will get the point.


#66

Is the issue really using the wrong command or the wrong update tool? Personally, I don’t think so.

The issue(for this thread) seems to be how the tools could be changed to make certain information more prevalent.


#67

small script for .bashrc (.zshrc) for view link announcement, only if “y” is in options
for pacman ( but easy transform for pamac-cli)
use xmlstarlet package

enabled with PACMAN_RSS environment variable

pacman(){
   if [[ -v PACMAN_RSS && "$1" =~ y ]]; then
     branch=$(pacman-conf | grep -oE -m 1 "unstable|stable|testing")
     # xmlstarlet ?
     if $(pacman -Qqi xmlstarlet &>/dev/null); then # by frog :)
        curl -s "https://forum.manjaro.org/c/announcements/${branch}-updates.rss" | xmlstarlet sel -T -t -m "/rss/channel/item[1]" -v title -n -v link -n -n
        # or xdg-open "$url" &> /dev/null
        read -n1 -p "Continue upgrade ? (y/N) "  gonext # pause
        [[ "${gonext^}" != "Y" ]] && { echo ""; return; }
        #zsh: read "gonext?Continue upgrade ? (y/N) "
        #zsh: [[ "${gonext:u}" != "Y" ]] && { echo ""; return; }
    else
        echo -n ""
        #echo "package xmlstarlet not installed !"
    fi
   fi
   /usr/bin/pacman $*
}
#alias pacman='__pacman'

output:

[Stable Update] 2019-01-23 - Kernels, Mesa, Browsers, Nvidia, Deepin, VirtualBox
https://forum.manjaro.org/t/stable-update-2019-01-23-kernels-mesa-browsers-nvidia-deepin-virtualbox/72986
continue upgrade ? (y/N) n

#68

Yes, and (see OP) ideally suggest or link to the best way of handling it.
So an ‘update-notifier’ would just notify about special care and an ‘update-manager’ would also suggest the best move forward.


#69

Could it have been simpler to test if xmlstartlet is installed with pacman -Qi xmlstartlet and use the exit status instead?

Continue*

FIFY


#72

That would be good. I already use btrfs, and have roled back 2 or 3 times now.


#73

I think it’s all well and good to have a pop up notification system in place for new/unsophisticated users. However mark my words, one of the most frequent posts on the forum after something like this is implemented will be “how do I disable that annoying pop up notification”. :smile:


#74

Easier to answer than how to explain to chroot a broken system :wink:


#75

This holy grail is vapourware, there is no golden chalice to guarantee flawless updates for those disinclined to read, disinterested in learning.

Arch is not Linux novice suitable, Manjaro is not Linux novice suitable, pretending it can be made so with a different update manager is folly.

If you lack knowledge read the announcements so you know what to expect, backup regularly just in case, and wait a day or two before applying updates so you know of any potential issues others have faced.

Expectations management is the key, not bloody “magical” update tools.

LOL, then btrfs spectacularly, explosively 5h1t5 itself and people have broken systems anyway.

Once bitten … never again … it is certainly not a default file system for the masses.


#76

I never asked for magical update tools. I very much lowered my bar to not-so-magical information tools to do exactly what suggest: that users get to read the announcements. The present system makes it easy to ignore them until it goes boom.

It does not appear technically meaningful to me to implement all kind of user-friendliness (installer HW detection, stable branch, GUI package managers) in order to end up with a time-bomb.


#77

Just to say, yes, I keep moving this thread. I’ll stop now.


#78

This post was flagged by the community and is temporarily hidden.