I’m expecting them to revert back to the old binary in dir layout breaking the update yet again for those of us that did the workaround.
We will have to do a workaround for the workaround soon 
1 Like
Why is replacing a directory with a file enough of a problem that it prevents RPM applying the update? This seems a little silly — surely package structures change quite often.
1 Like
It’s very silly indeed, distro makers should all get together and agree on a better, universal packaging format. Starting with a working group and a draft RFC.
One can hope 
1 Like
@pavinjoseph that’s right it should all be rpm and zypper… 
1 Like
Zypper 
RPM 
From my limited interaction with the zypper devs, it’s mostly RPM that’s holding zypper back!
Zypper… 
Flatpak should be the new one.
So your assertion is that when a package manager wants to do something hinky, that could potentially break things, it should just YOLO and do it anyway, without informing the user?
That’s not a package manager I’d want to use.
1 Like
1 Like
Wow, a really trustworthy site…NOT! No date. No name. Outdated and false claims. Misunderstanding how updates work.
@hui, indeed, the author of that website is known for making unsubstantiated and primarily emotional assertions about technologies he dislikes primarily due to stubbornness than a desire to constructively criticise. However, a significant amount of the fundamental flaws he mentions, and some unlisted issues I personally encounter frequently during packaging discussions and usage, do indeed apply to Flatpak.
For instance, its total inability to support easy offline installation using a single installer file, like every other format in the world (even MSIX, its direct Windows competitor!) and the fact that one cannot develop and unsandboxed application using it, if library abstraction and duplication are undesirable.
I tend to find that using its Portal technology within a standard application format affords the user permission management of AOSP’s APK and Windows 10/11’s MSIX formats whilst providing the application packager with the ability to interact properly with system components not provided by those portals, and allowing the user to gain the benefits of distribution-provided security updates.
Regardless, for its current purpose — allowing an application compiled for a generic Linux+HFS base to operate on almost all Linux+HFS-based OSes (even those without GNU utilities, like Alpine) — it works brilliantly. (I specify HFS-based because that weird Snapcraft IoT OS from Canonical doesn’t support it not least due to its FS structure.)
@sfalken, I don’t know what you’re referring to. I see which post you’re responding to, but I don’t see any part of it which could constitute the context for such a question.
@pavinjoseph, how? This is the first time I’ve heard of this. I thought that Deb and RPM were quite identical, although perhaps you believe both are retrograde?
I agree. At the very least, an extensible standard with mandatory standardized core components (like Wayland is doing, but hopefully this would be managed by people with slightly more open minds) would provide the flexibility which obviously the OS developers desire (considering their current myriad package formats).
Have you considered organizing something like this yourself? I expect a lack of necessary tenacity on behalf of those who have already tried has contributed to this mess.
1 Like
I used to hang around the Github repos of zypp and zypper while building zypperoni, got to interact with the devs a bit. For instance, async installation is never happening in zypper as RPM doesn’t support it and there are no plans to support it. The somewhat faster way of installing packages using RPM single transaction has weird requirements that sees zypper trying to download all the packages in advance even if you’re doing just a dry run, and so on.
Deb is easier for end-users to unpack, modify, repack IME. There is a single package dpkg-deb to unpack and repack (as easy to use as xz). Once unpacked, the files/executables it installs and all the pre/post installation and removal scripts are neatly stored in its own separate folder/file. You just modify the file(s) you want and call dpkg-deb to repack the folder.
With RPM, you have to unpack, get the pre/post scripts separately, build your own specfile…
Also, rpm is slow compare do deb. Both dnf and zypper suffer due to this.
Though both have made strides to paper over these limitations in their own way.
At the very least, an extensible standard with mandatory standardized core components (like Wayland
Like minds think alike. I was thinking of Wayland (and pipewire) too when I wrote that comment. If it could largely replace the mess that is X11 in short order (sees initial release was in 2008 
), I don’t see why package managers can’t do the same.
1 Like
1 Like
@pavinjoseph Computers are tools, just like a hammer, you need to learn how to use it… else you will always be smacking a finger or thumb…
2 Likes
@malcolmlewis, I have no idea what you mean by that.
@sfalken, if you’re responding to Unable to install update to `virtiofsd-1.10.1-3.1.x86_64`. What to do? - #33 by pavinjoseph, that XKCD only applies when no effort is made to replace the previous standards. Merely because some of those standards might continue to be utilized by niche distributions in limited capacities does not indicate that they would be of consequence.
@rokejulianlockhart it was in reply to @pavinjoseph to clarify, it’s just as easy with rpm src files, as your user rpmbuild --rebuild <some src rpm> pops it all into $HOME/rpmbuild, then you can drill down and modify spec file (no need creating) as required, rpmbuild -ba some.spec. The added bonus that you get is re-compiled binaries for your system (if want to some additional flags). For example, lc0 builds on OBS, grab the src rpm and rebuild locally and it detects the likes of nvcc to use cuda in the binary. You can also just pass arguments to rpm to do this or that. Everything gets done as your user, then can install the rebuilt rpm as root user…
But this thread is way off track now
1 Like
Oh, I did not know this!
Could be handy, though it requires building the RPM from source.
More work, could be missing dependencies for build. Not easy as an end-user especially if they wanted to fix the virtiofsd bug by modifying the RPM binary itself.
I mean in the context of this thread we’re talking about modifying a single path in a script and you’re suggesting building from source.
Btw, modifying the deb file has been handy for me when installing packages in distrobox without init for example. Some apps like Mullvad VPN’s binaries have scripts that depend on systemd, no way to install it without some modifications to just skip these checks in the script files.
1 Like