3 ms·

Sorry what? So you have to go read a news site if it is OK to update your packages? What the hell is the point of having "rolling distro with all the new shit"

Sorry what? So you have to go read a news site if it is OK to update your packages? What the hell is the point of having "rolling distro with all the new shit" if you have to be constantly afraid if you can update your packages or not? >you should upgrade often But you litereally started by saying that upgrading any given Friday is not quranteed to leave you with working OS

seba_dos1 5y ago
> So you have to go read a news site if it is OK to update your packages? Not "if it's ok to update", but "whether there's manual intervention required". See https://wiki.archlinux.org/title/General_recommendations#Package_management https://wiki.archlinux.org/title/General_recommendations#Pac.... Not reading that before upgrade seems to be the main reason for post-upgrade failures. > But you litereally started by saying that upgrading any given Friday The point was that you should rather upgrade "every Friday" than "any given Friday".
bscphil 5y ago
This is literally intended. Arch is a rolling release distribution, and more than that, it's a distribution which sticks very closely to upstream and tries to have a single correct way to do things. To have all those things at once, you have to have competent users who are willing and able to make changes to their system to keep up with the distribution. To give a practical example. In 2013 Arch Linux merged all binaries into /usr/bin. This architectural improvement was obviously a major change, and the way Arch is designed as a rolling distro meant that you couldn't leave users behind on the old way of doing things. After the change, everyone needed to be using the merged /usr/bin. This is a designed lack of backwards compatibility that means you're guaranteed to be using the latest system architecture at all times, reducing the maintenance burden for the maintainers and making sure everything just works most of the time. But it also means that you have to be willing to do system maintenance to get your local system in line with what the Arch devs use. In the case of the /usr/bin merge, manual steps to perform the upgrade were required. [1] They weren't hard, but Arch requires this kind of oversight as part of its design. If you're not willing to perform that kind of maintenance, then Do Not Use Arch! It's designed for people who are - although in practice this kind of intervention is required only about once a year. [1]https://archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/ https://archlinux.org/news/binaries-move-to-usrbin-requiring...

seba_dos1 5y ago

> So you have to go read a news site if it is OK to update your packages? Not "if it's ok to update", but "whether there's manual intervention required". See https://wiki.archlinux.org/title/General_recommendations#Package_management https://wiki.archlinux.org/title/General_recommendations#Pac.... Not reading that before upgrade seems to be the main reason for post-upgrade failures. > But you litereally started by saying that upgrading any given Friday The point was that you should rather upgrade "every Friday" than "any given Friday".

bscphil 5y ago

This is literally intended. Arch is a rolling release distribution, and more than that, it's a distribution which sticks very closely to upstream and tries to have a single correct way to do things. To have all those things at once, you have to have competent users who are willing and able to make changes to their system to keep up with the distribution. To give a practical example. In 2013 Arch Linux merged all binaries into /usr/bin. This architectural improvement was obviously a major change, and the way Arch is designed as a rolling distro meant that you couldn't leave users behind on the old way of doing things. After the change, everyone needed to be using the merged /usr/bin. This is a designed lack of backwards compatibility that means you're guaranteed to be using the latest system architecture at all times, reducing the maintenance burden for the maintainers and making sure everything just works most of the time. But it also means that you have to be willing to do system maintenance to get your local system in line with what the Arch devs use. In the case of the /usr/bin merge, manual steps to perform the upgrade were required. [1] They weren't hard, but Arch requires this kind of oversight as part of its design. If you're not willing to perform that kind of maintenance, then Do Not Use Arch! It's designed for people who are - although in practice this kind of intervention is required only about once a year. [1]https://archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/ https://archlinux.org/news/binaries-move-to-usrbin-requiring...