--rollback features request

[mirh]

So.. This would be really important to my use case (way more than the other petty issues I reported tonight), but I get that they aren't a walk in the park, so let's just this be a place to see if the wishlist is feasible at all.

• [ ] the command should be able to work in combination with --pkg
• I get partial {up,down}grades are the eleventh plage of egypt.. But if what you are actually caring for is bisecting in the name of bug hunting (and not current system stability), they are important
• [ ] you shouldn't touch the system /etc/pacman.d/mirrorlist (or is that me dumb not using the hook?)
  • can't you like pass a temporary file to pacman --config? Or what am I missing here?

[JustinTimperio]

In Order:

1. What command should be used in combo?
2. What?
3. Changing the Mirrorlist is completely fine. It is also not used in anything other than the rollback to date command. See: https://wiki.archlinux.org/index.php/Arch_Linux_Archive#How_to_restore_all_packages_to_a_specific_date
4. I'm not really sure what you mean. Like an RP metafile you moved from somewhere else?

[mirh]

--pkg and --rollback. Which I see might be me again not understanding the purpose of this utility, but it would have been pretty helpful when I was bisecting some mysterious regression.

Then, I guess like it didn't came to me that the utility made a backup, and that you also had to go through it to rollback the rollback.

[JustinTimperio]

Yeah, I think this is just some confusion about how these functions work.

--pkg is a feature request someone put in on reddit when they needed to rollback a few individual packages, rather than restore the full state of the package versioning. When you run -pkg it uses your input to search the filesystem for anything matching the name.

--rollback is a full system state of packages and needs to be generated ahead of time so you have a state to fall back on. --hook and -Syu also create restore points but their creation is automated and they are not available for use with the --rollback command.

Please check the documentation as most of this is covered in the docs. I'm gonna close this and label it for newcomers

[mirh]

I mean.. It depends if this "no strings attached" mode is something that you may also wish supported somehow, or not?

[JustinTimperio]

What on earth is a "no strings attached mode"? The project automates system package states and restoration. Strings are always attached.

Like I'm super open to user feedback but a lot of this input has been total gibberish. Opening up tons of issues without seemingly ever reading the docs is not cool. The docs layout how the file structure works, which commands can be combined, numerous examples and even an explanation of the underlying design itself. "no strings attached" mode doesn't actually describe anything.

[mirh]

With the exception of this one, which I even had a premise about though, I don't think I stepped anywhere outside the scope of the project. Put aside, that even looking at the readme again now, hooks really don't seem essential to it.

Anyway, "no strings attached mode" means that you just help the user with the immediate downgrade (as a supersized downgrade) and end of it. No hooks, no mirrors editing and no restore points (for as much as every user has its use case then).

In my scenario, having --rollback being able to apply only to some selected packages would have been really appreciated. Yes, it's a niche usage probably, yes I could eventually did it someway by running rb and pkg separately, and no I'm not pretending it to be added if it's outside your vision. If I seemed pretentious, it's just because that shiny documentation made me think pacback was already 200% polished and done.

[JustinTimperio]

Na, I wrote it in a few weeks with my spare time. I believe in strong documentation but pacback is literally only 2-3 months old.

Okay, so that request is starting to make more sense. I still don't think I understand your 'immediate downgrade/supersized downgrade' but I understand wanting to rollback sets of packages. I have considered this, but in practice, it's an awful idea.

First, if you have a set of packages that you need to tightly control, hold them in pacman.conf. Second, pacback's core objective is to be stable and consistent. Downgrading specific packages(xorg, nvidia, gcc) can be catastrophic to other applications(if versions aren't synced) and I really don't want to be the reason you need to boot into recovery mode. Third, there is no way for pacback to know what your system looked like before without creating some data. Like this is a new feature not provided by pacman or arch. I'm not just parsing a pacman log and working backward. Without a restore point, I have no way of knowing which packages were actually stable together. I could take the second to the latest version in the cache, but this is an unsafe solution for a bunch of reasons.

The point of the hook is that you install it and whenever you need to undo your last upgrade(could be one package or a thousand) you simply call --snapback. If you want to mark a permanent stable point you create restore point with --create_rp.

[mirh]

"Supersized downgrade" as in, literally the tool. I feel really dumb for not having realized how confusing mixing it up with the "verb" could be.

First, if you have a set of packages that you need to tightly control, hold them in pacman.conf.

Oh, lol, yes. Once found the offending package, if its upstream isn't quick to deliver a fix, of course that's the only thing making sense. Guess like this makes it not so much "without strings" anymore. Still...

can be catastrophic to other applications(if versions aren't synced)

Hence my quite messy premise above. I see how it can't be stated enough then... though, honestly, if you are already playing in downgrade-land, the expectation would be you aren't really a kid.

If it can make you feel more accustomed, just think that if you rollback everything to 2018 (i.e. complete downgrade, not partial), it will *still* break nonetheless... because systemd-libs won't find glibc 2.30, and pacman won't install libsystemd in its place because it has been marked "replaced" and (not explicitly installed?) packages aren't handled /s

Third, there is no way for pacback to know what your system looked like before without creating some data.

It's not needed? My "stable reference" is the current/actual packages. I'm very sorry if I can't quite put my finger over why such allegedly simple idea is so hard to picture.

[JustinTimperio]

O LOL, so that was not clear. This makes way more sense now.

So I agree once you get into downgrade territory it gets dangerous, but its actually more stable than you think. I haven't had really any issues falling back short distances(a few days to weeks). I'll do some testing this weekend to actually confirm some of this. If you want to talk more about your idea checkout the gitter. Its a way easier way to talk. https://gitter.im/pacback/community