Arch Linux's Pacman 6.1 Released With Cache Server Support

[archkde]

The power loss problem could be mitigated by writing all files to disk and then just "mv"-ing then into place. That operation should be pretty much instant and minimize risk. I wonder why nobody's doing that.

Not really, since you still need many renames (and they can add up quite a lot). You need to leave the old system in place and use an actually atomic operation to switch to the new one, for example filesystem snapshots (see MicroOS), repointing symlinks (Silverblue) or bootloader configuration (NixOS) or A/B partitions (Android or SteamOS).

[varikonniemi]

Since when is a programmers skill measured in who they cater to? Maybe it's the best programmer in the world but just want's to support advanced users in his free time coding project?
.

How to measure skill? Someone creating doom in brainfuck after spending 10 years isolated in a basement is seen as skill to some people. I see this is the market you target, the ultimate hacker that knows someone just pacman -Scc && pacman -Syy && pacman -S $(pacman -Qqn) instead of pacman repair

After all, who did not see that shifting that comma 42 steps to the left obviously meant that doom would run fullscreen instead of a window?!

[Anux]

I see this is the market you target

What market? Am I earning money with my posts? Please send it to me, thanks.

No you are just creating a straw men, because you lack any arguments.

[varikonniemi]

don't be disingenuous. Your comments target an elitist market that think what you say is sane.

There are real world issues that would be easily solved in pacman, and you attack me for bringing this up

You are so deeply elitist that you don't even see how this would be generally beneficial. Much of paccheck functionality should be in pacman, and integrated. So that you could run "pacman repair"

[fallingcats]

No, what they're talking about is atomicity, i.e. implement a way to ensure that either the transaction happens completely or it doesn't happen at all. The thing is, writing all changes to disk in a separate location and then mv-ing them to place is also prone to the same issues, because what happens if the power loss occurs during the mv operation? Same exact thing.

That's the kind of issue that immutability and A/B partitioning have been created to solve. Write the changes to disk, ensure their integrity, then switch to using them right from where they are, and mark the old files as deprecated.

Not really, since you still need many renames (and they can add up quite a lot). You need to leave the old system in place and use an actually atomic operation to switch to the new one, for example filesystem snapshots (see MicroOS), repointing symlinks (Silverblue) or bootloader configuration (NixOS) or A/B partitions (Android or SteamOS).

RE: what happens if the power loss occurs during the mv operation?

The mv is pretty much instant, as long as src and dst are on the same filesystem it's just a rename call under the hood. This would be orders of magnitude less likely to go wrong than the current situation. I know other approaches to package management wouldn't have those issues, but the point of my suggestion was to be a minimally invasive change.

[Anux]

don't be disingenuous. Your comments target an elitist market that think what you say is sane.

Do you know what a market is?
If you think I'm wrong you could use arguments to prove that instead of creating your market straw men.

There are real world issues that would be easily solved in pacman, and you attack me for bringing this up

Hey calm down, there was no attack, maybe you misinterpreted my words? I just pointed out that pacman is a bad choice to battle your power loss problems because that would only repair your arch install in the best case. Your personal data should be much more valuable and a backup not only resolves all bit rot and data loss problems but fix arch too. Use the right tool for the job. You always should have backups anyway.

You are so deeply elitist that you don't even see how this would be generally beneficial. Much of paccheck functionality should be in pacman, and integrated. So that you could run "pacman repair"

I totally see the benefits of easy commands or even better a click GUI and make heavy use of them, but that's not what arch/pacman is about, it's about understanding what you are doing and learning about the inner workings of your distro. If you don't want to do that then you have made a bad decision in choosing an arch based distro, there are tons of alternatives out there from ubuntu to arch and everything in between.

Why does pacman need to have that functionality if it's provided elsewhere? If you want paccheck functionality then by all means use it, that's what free software is all about. Use what you like and improve what you don't like.
You could make a pacman wrapper that reduces all pacman commands to 5 letters and if arch users love it it might even become the new way of package management in arch.

[murlakatamenka]

I rust arch with pacman as much as any other distro

In rust we rust!

[Quackdoc]

In rust we rust!

jesus christ I need to go touch grass for a bit

[Jaxad0127]

The mv is pretty much instant, as long as src and dst are on the same filesystem it's just a rename call under the hood. This would be orders of magnitude less likely to go wrong than the current situation. I know other approaches to package management wouldn't have those issues, but the point of my suggestion was to be a minimally invasive change.

The issue is that it isn't ONE mv command for the update, it's one per changed file. 10 files changed, 10 mv commands. The alternatives listed have one command / boot update no matter how much was changed.

[Yndoendo]

Interesting. I've been using a NFS mount as a cache server for some time now (by just mounting it over /var/cache/pacman/pkg). How exactly does the new feature work? What protocol does it use to cache the packages to the server? And would it still cache packages locally if you use that?

Mine is just a local HTTP server that hosts packages like a partial mirror. Have some scripts that rsync to server after updates and clear out the local cache. This way if the server is hot around, updating just skips that local sever and moves onto the next. This also allows for retaining older packages in case MESA or some other package has a regression just for a single type of hardware or computer.

Most likely the local cache server will not error out and complain as much when it cannot find the package. I find it best to comment out the partial mirror in the mirrorlist while traveling to remove timeout delays. Will spend time looking into as an alternative to the partial mirror.

pacman is also the package manager used by MSYS2.