istinnjazz wrote:But in general I think it will never be straight foreword. But some ideas could help the health of growing up the system with installations. But this will always be under the "base" of manjaro/openrc update idiosyncrasy. The way someone would keep a heavily used system updated with minimal conflicts, would be a challenge. The rolling release is by it self prone to incompatibilities or system explosions but the aufs system layering could also add some possible inconsistency also. Or am I wrong?
i think that's a fair assessment ..
(one of )the key(s) to (user) updating is knowing(or finding)(keeping track of) where everything is, so the smaller and simpler the setup, the easier(or more possible) that will be..
not to mention hardware quirks(compiled drivers etc..)
ultimately, if brokenman chooses to return to this manjaro base for future porteus, (i think) each iteration would be a 'rebuild from scratch' process(far easier to script)
possibly on a three month cycle(notwithstanding urgent security patches)
which still leaves the user with 'my stuff is broken' possibilities...
a tricky thing to balance.. lightweight live vs up to date and complete...
I see, I'm glad you have a similar view and your points make sense. real helpful for everyone.
I have some notes on my experiments update on my used system, I will point the basic stuff as my system is a personal case.
1. be careful on xorg, it is good to have this in different base module. Hopefully it will not get a conflict with the core module in the future by unresolved dependencies. I have disabled every related package in pamac (xorg*, xf*). Pacman simple update (Pacman -Syu) cannot do this exclusion easily, and in this case some driver may conflict. For example no gui for xorg 1.19 for me and nvidia drivers.
2. Use pamac. Update it first. You will see some or all of possible conflicts before downloading the packages. Pamac will keep all the downloaded packages in its cache directory so you can use them even if you have no Internet access (happened due to networkmanager conflict).
Newest pamac resolves the issue with the message box that you couldnot read all the informatio, e.g. hundrends of conflicting permissions, common @ nemesis.
Resolved @ v4.3.4. I have needed an other package also to use this.
3. There are some odd permission issues when reinstalling, uninstalling. You have to manually delete files for the update process to continue for single packages or on an update process. This is a known problem (bug?) not resolved.
4. Find a way to have wifi wlan access via console so to avoid problems with net access. (example: iw package). I propose to add this to core.
5. Network manager had issues here. At least 3-4 packages conflicted until the service was up and running. Classic conflicting case. The savefile had an updated version install, since 3.5 version, by using the update there was versioning conflict with the new openrc and maybe new login system.
Files downloaded manually from a manjaro mirror from an other os, added to pacman cache, installed etc. with pacman -S, sometimes pacman -Sd command.
Dbus was one of them. Logout menu has now all the commands in place (had been disappeared except logout).
6. read about the openrc services commands and see what has happend to those services, try to restart failed services and log error messages. So those messages may point you to the right packages to (re)install and pacman will lead you to uninstall the conflicting ones...
But be careful as you have to know the new package to use... (dbus, elogin-dbus) sometimes you have to reinstall even the conflicting one, and then exchange with the new. So there might be opposite questions from pacman to unistall a conflicting package over an other.
7. backup savefile/native on every successful step or you may cannot go back, or at least log some good moves.
8. Some system explosions never logged (brutal un-installations, failed full system updates etc..), just to see the behaviour of the new base (xorg1.19/nvidia340.96 fail for example, nvidia driver will always be a xzm for me for obvious reasons, like the gui.xzm)
9. Uninstall a package and install it as a xzm if you need to avoid its existence in savefile (or need to exchange versions with core), e.g gcc. Still need to see what kind of stuff it is better to use as xzm modules.
10... still there are conflicting versions everywhere, hopefully there are no more conflicting packages that could break the functionality. The scenario... THIS-UPDATE-->SAVEFILE-->CURRENT-BASE to be of different versions is common. And the only info I have about this is the pacman database error message
.. to be continued, the update process has not been finished, this could take some time, it is a good way to refresh some linux knowledge