Manual interventions - what you need to know


(Neofytos Kolokotronis) #1

Chakra is a half-rolling distro and since development is always ongoing we continuously introduce new technologies and changes to all our users. From time to time we ask you to manually intervene for an upgrade, so I wanted to try and explain our thinking behind it.

The main reason we ask you to put in the extra effort is that we want users to be informed on important changes to their systems and able to go ahead with upgrades on their own time, without risking breaking their system at a time they need it or forcing a change that affects their workflow.

We try our best to avoid these situations where you have to manually intervene, but unfortunately they are sometimes inevitable. We could perhaps automate the procedure in some cases by pushing it on everybody’s systems in the background. But we prefer not to do this, especially when it concerns important packages or changes.

The most common reasons for requesting from users to take manual steps are changes in packaging (upstream, chakra-specific, obsolete), in system (move to systemd, /usr merge) and in our services (repository restructure).

Looking at the statistics, manual intervention was needed one or two times per year in the past:

  • 2011 - 1
  • 2012 - 1
  • 2013 - 1, 2
  • 2014 - 1
  • 2015 - 1, 2
  • 2016 - 1, 2
  • 2017 - 1, 2

Konqis by KDE under CC BY-SA

The main complaint about having to manually intervene is that it can be frustrating to some of you as you need to stop and take the time to properly maintain your system, other than performing a regular upgrade through pacman or octopi.

The advantage we see here is that you stay up to date with the changes that affect your system. You do not end up with a broken system without knowing what it is about. This makes it easier for you to troubleshoot any problems and for us to help you on issues that occurred over specific changes.

Maybe if you are new to Chakra or not used to the command line interface, you might not feel confident enough to do the procedure. We have all been there, so we always make sure to post a #news announcement and share it on all our social networks accounts when this is required. We try to explain clearly why this is needed and how to proceed, and include simple instructions that most users can follow. We hope that through this process you also get familiar with some commands and learn a thing or two on how your system works. :slight_smile:

We will try in the future to get an ISO out as quickly as possible when manual interventions are needed, so new users do not have to come across them on their first upgrade after a new installation.

Do you see any other advantages, disadvantages or things we could improve related to this?

(Chroot Doot âśť) #2

How would Akabei affect “Manual interventions”, as they’re called?

(Hans Tovetjärn) #3

GLEP 42 is tangentially related to this discussion:

(Neofytos Kolokotronis) #4

@AlmAck and @shainer will know more on if and how akabei can help workaround any pacman limitations related to this.

My dream has always been to be able to push a warning message via the package manager to the users that are affected, informing them on what needs to be done and requesting permission before proceeding with the upgrade. This is the only guaranteed way I could think of so every user is notified.
If I understand correctly this is more or less what Gentoo is also discussing in the post @totte shared?

(Luca Giambonini) #5

At the beginning akabei will behave similar to pacman. Based on the use case would be possible that we are able to integrate into akabei the conflict resolver that automatically update your system. As you saw this are very rare conditions (1-2 per year) where pacman is not able to solve the dependencies.

(Neofytos Kolokotronis) #6

This topic was automatically closed 170 days after the last reply. New replies are no longer allowed.