I’d simply archive with fsarchiver all partitions the system is composed of. Or only selected folders you’re interested in.
Backups, made with fsarchiver, may be restored later to another partition, to another computer, to the same or another partition, of equal or different sizes. Full freedom in partitions manipulation.
Fsarchiver is present by default in all distros, except Solus. It’s also included in various rescue tools, such as SystemRescueCD.
I think I got it, and now I understand more of how pacman’s remove options work.
The one thing remaining from Antergos seems to be my /etc/os-release and /etc/issue files, identifying the system as Antergos…
(A side note: /etc/os-release is a softlink, not a real file; it points to real file /usr/lib/os-release)
Both os-release and issue files may be modified by a user, obviously, with caution. It’s what we’re doing installing native Arch. For example, mine are modified in such a way that they report AnteFree Gnome instead of default Antergos Linux:
One way to remove a package only, without its dependencies, is to remove it by -Rd command.
Its a bad way to uninstall something. Arch is made by dependencies, not by packages. The -Rd breaks all dependencies, leading to troubles. But sometimes it is inevitable. For example, to remove the dammned meta-packages, introduced in Antergos.
I don’t use subversion. But gksu is indicated as an optional, not mandatory dependency for it. It’s important to not remove subversion itself; gksu, which it optionally wants, you’ll install later.
Are these others safe to remove as well?
Do not remove anything, until pacman proposes to remove only gksu itself.
gksu may be installed later back again. From AUR or numerous 3rd-party repos.
Do it by gradually reducing “removal power” of the -R command. How to achieve it is explained just 4 (four) posts above your’s one, in this thread, just sccroll the topic a bit higher, it’s here.
It’s impossible to provide exact step-by-step instructions for each and every Antergos system configs in the world.
…At that point a few packages went ahead and updated themselves from AUR…
Obviously, I can’t respond for repo’s maintainer. But slightly newer AUR pkgs is a quite common thing for most precompiled 3rd-party repos.
As you know, AUR doesn’t have any package at all. You compile a package from sources, on your local computer, according to instructions contained in PKGBUILDs.
Repo’s maintainer must do all that job for us. He must follow the most recent sources versions, compile them on his hardware, must distribute compiled pkgs to server(s) and mirror(s).
PKGBUILDs in AUR practically don’t require any maintenance at all. Arch repos are maintained by hundreds of people. Most 3rd-party repos are maintained by one person.
Keeping everything up-to-date seems to be rather big job for one maintainer.
…what’s with the .sig thing?..
There were very long discussions about .sig in various forums. The most useful was in Arch forum some years ago.
If I understood correctly, a definitive answer was not found.
Again, if I didn’t misunderstand, it happens for signed repos only - but not always, - and is due to not very correct work of some mirrors.
At that time, I was satisfied with this explanation.
.sig aren’t real repos, they are void (empty), don’t contain any package. Their presence is harmless.
@thegoliath Thank you very much for kind explanation and detailed description of what was happened.
[disastrousaur] works without a problem again.
I was about to respond that few minutes ago I upgraded some Arch systems without any problem. All systems use your repo. An example:
:: Synchronizing package databases... core 132.5 KiB 8.08M/s 00:00 [---------] 100% extra 1630.7 KiB 10.6M/s 00:00 [---------] 100% community 4.9 MiB 5.70M/s 00:01 [---------] 100% multilib 170.5 KiB 9.80M/s 00:00 [---------] 100% bluestar-override 29.0 B 0.00B/s 00:00 [---------] 100% bluestar 72.4 KiB 247K/s 00:00 [---------] 100% disastrousaur 184.1 KiB 1898K/s 00:00 [---------] 100% disastrousaur.sig 119.0 B 0.00B/s 00:00 [---------] 100% herecura 58.7 KiB 587K/s 00:00 [---------] 100% revenge_repo 38.9 KiB 1051K/s 00:00 [---------] 100% Foreign packages: | 4 / 4
I didn’t know how to explain the fact that there were some problems with your key a few days ago, but now (2019.08.01 12:20 local time) [disastrousaur] works perfectly again.
Your post explains everything.
ArchWiki warns about the fact that [disastrousaur] is currently under maintenance. It also states that inconveniences will be solved “in next week”. The warning is there for some months now. The “next week” is not clearly defined.
As a temporarily workaround it is possible to switch off checks for repo’s key. Simply add below the repo’s name (in square brackets) and above the server’s address (with URL) one more line:
SigLevel = Optional TrustAll
The error message should disappear, once the line is added. The line may be removed later, when | if the error with the key will be solved.