You're viewing a single thread.
I think this is funny, but it's hard for me to hate too much on flatpaks. Disk space is practically free now, and having spent a good chunk of my career fighting DLL hell, I have a lot of sympathy for the problem it's trying to solve.
Yeah I mean it's taking 500G of my terrabyte ssd. What else was I going to use that for? Installing games off steam? Two node modules folders?
Two node modules folders?
LOL
Its good and bad. Bad because the base system cant use it and its not the main packaging choice.
Lots of good apps like OBS use outdated runtimes, which simply should not be used anymore. I am not sure if this is a security issue but probably it is, and it creates this unnecessary Runtime bloat.
I hate this philosophy so much! I hate developers for it! It's like they gave up on even trying to do anything about retrocompatibility and managing libraries and dependancies.
Anyway it will collapse soon. I just wish it was sooner.
You're free to hate it, but flatpaks ARE an answer to "retrocompatibility and managing libraries and dependancies."
An answer that posit that disk space is infinite and free and embrace the black box philosophy. Soon we will have machine priests doing rituals to maintain them I guess.
How do Flatpaks follow "black box philosophy"?
That sound cool tho happy admech noises
Honestly I get both sides of it. Your view makes sense as an end-user and from a philosophical perspective. But some people have legacy software that needs conflicting dependency versions, for instance. It’s just a trade-off.
Yeah, package maintainers should have their dependencies figured out. "Managing dependencies is too hard" is a distro packager's problem to figure out, and isn't a user problem. When they solve it and give you a package, you don't need to figure it out anymore.
Plus, frequent breaking changes in library APIs is a big no-no, so this is avoided whenever possible by responsible authors. Additionally, authors relying on libs with shitty practices is also a no-no. But again, you don't need to worry about dependences because your packager figured this out, included the correct files with working links, and gave them to you as a solved problem.
Honestly this. It's so nice to not have to hunt for a specific library that depends on 20 other libraries. I'd rather pay in disk space than deal with that.
You also pay in security holes.
Some people have limited bandwidth for downloads, and a simple program can run to more space than a basic distro.
I can't use flatpak because each update for a few apps is hundreds of megs and my internet is only 2 Mbps.
That too :-/
it's trying to solve.
It does not solve it. It just slaps more DLLs on top. Package managers do.
Pacman's output "error: failed to prepare transaction (conflicting dependencies)" seems to disagree with you.
More info
Fine.
https://wiki.archlinux.org/title/Pacman#%22Failed_to_commit_transaction_(conflicting_files)%22_error
Here's the pacman documentation explicitly stating that BY DESIGN it will not resolve a file conflict for you by overwriting files.
You either don't understand what's being discussed here, or you're trolling. Google it yourself if you want to know more.
This is conflicting files, it indeed means that different packages try to install same files(usually happens when same package have multiple names).
But this is different error from what you mentioned before. So I'm asking what dependencies conflict in your case? Libboost?
You either don't understand what's being discussed here, or you're trolling. Google it yourself if you want to know more.
I ask what dependencies cause conflict. And why did you provide link to another error? Your comment has conflicting dependencies too.