Bottles Is Sick Of Downstream Linux Distro Packages
ฝัง
- เผยแพร่เมื่อ 19 ก.ย. 2024
- Bottles and it's developers are very much in favour of upstream packaging and flatpaks especially after the situation they dealt with because of broken outdated packaging coming from Fedora Linux
==========Support The Channel==========
► $100 Linode Credit: brodierobertso...
► Patreon: brodierobertso...
► Paypal: brodierobertso...
► Liberapay: brodierobertso...
► Amazon USA: brodierobertso...
==========Resources==========
Bottles Issue: github.com/bot...
Fedora Issue: bugzilla.redha...
Fedora Mailing List: lists.fedorapr...
=========Video Platforms==========
🎥 Odysee: brodierobertso...
🎥 Podcast: techovertea.xy...
🎮 Gaming: brodierobertso...
==========Social Media==========
🎤 Discord: brodierobertso...
🎤 Matrix Space: brodierobertso...
🐦 Twitter: brodierobertso...
🌐 Mastodon: brodierobertso...
🖥️ GitHub: brodierobertso...
==========Credits==========
🎨 Channel Art:
Profile Picture:
/ supercozman_draws
🎵 Ending music
Track: Debris & Jonth - Game Time [NCS Release]
Music provided by NoCopyrightSounds.
Watch: • Debris & Jonth - Game ...
Free Download / Stream: ncs.io/GameTime
#Linux #OpenSource #Bottles #FOSS #LinuxGaming #LinuxDesktop
DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation.
![วันเกิดเธอ (TO YOU) - PHUWIN [ OFFICIAL MV ]](http://i.ytimg.com/vi/_ROx1Bj3T0Y/mqdefault.jpg)
I find this situation to be really... Odd. I agree 100% with the Bottles devs. If I were to make an unofficial Fedora spin, let's say "Arodef" (Fedora backwards) and mucked about with it, but left all the support links to Fedora's Bugzilla - I imagine they wouldn't be all that happy, right?
On top of that you kept the name Fedora, and using mad seo skills have your website listed first… yeah
Detecting wrong dependencies or indicating in the UI that the app was built in an unsupported environment seems like a great solution tbh.
inb4 the distro maintainers patching that out
@@marcogenovesi8570 Then upstream can pull a Mozilla and force packagers to change the name if they do that (using Trademark law).
Yeah, I found it particularly funny when the packagers basically said "distributing our package with known non-buggy dependencies is too onerous."
Yeah that's a great solution, Magisk does this too
I think Bottles is being completely reasonable. Fedora can package all they want, but they won't support anything they themselves didn't package. They're not telling Fedora they can't package, they're just advising against packaging. In no way are they restricting Fedora from doing what Fedora is going to do, they just don't want it to come back to them when Fedora makes a mistake.
Correct. The Bottles developers are quite reasonable in their worries and their response, and I think Fedora packagers are also reasonable in wanting to package a useful FOSS software for their users. Furthermore I think the Bottles devs solution to having a custom, distribution specific, support links is brilliant and should solve everyone's worries, and I don't understand why it wasn't just finalized with that.
I think Bottles has the right idea here. Most FOSS projects are ran by a small team of Devs and they don't have the time or resources to resolve distro specific bugs. Fedora (or anyone else for that matter) has a right to take the code and repackage it, but if the repack leads to any issues it should fall on the shoulders of the person/group who repacked it and not the original Dev IMHO.
yea, I don't see issue for fedora with bottles solution. I mean are they seriously asking bottles devs to test if issue exists in flatpack version and if not then transfer issue to fedora team? If Fedora wants to build their own packages, why are they demanding someone to test if it works on official build? Personally I think what fedora is asking is not fair towards bottles project and what Bottles project suggest is perfectly ok. If you want to build it your self and distribute, then you also support your users and offer them contact point. Kinda reminds me of security issue in WIndows because they used old package of some well known linux app, and issue was that windows was using very old version of the app. That was also distributed by microsoft and developer asked people to contact microsoft not him.
It seems entire Bottles concern are links and message. They could have easily patched links half a year ago, replaced with official by Flatpak build.
This drama seems premature.
This is giving me MultiMC vibes (original author want total control on packaging, and community pushes back for security reasons, etc.), and when that happens they got forked multiple times. Maybe this time it would also be like that, which may be what both sides want after all.
I like how it still shows up in the store BEFORE the official Flatpak
I thoguht fedora switched to recommending flatpaks first and repo second?
@@wisnoskij Bottles is listed as two separate applications in GNOME software on Fedora for some reason, and the RPM package shows up ahead of it in search results. You're right that flatpaks have priority when apps are listed correctly though.
@@wisnoskij There must be `if(name === 'bottles')...`
I'm with Bottles on this, despite being someone who does prefer distro packages in general. The number of times I've been excited because Fedora has a package for something, only to find its so grossly out of date it plain doesn't work. For all the reasons mentioned in the video, sometimes a distro package just is not practical and its especially so with anything WINE related.
I think that in this case its just a matter of fedoras maintainers not looking at this reasonably. If this was a less complex app id say por que no los dose. But bottles is a very complicated app. My only complaint with the flatpak is it being gtk as a primarily kde user but this is a super minor gripe that can be lived with. I think this is a case of native versus the universal packaging formats getting taken too far
I agree. Universal packaging formats just have a *_lot_* of downsides people completely avoid mentioning, but none the less in specific usecases they're benefits still make them worthwhile. It's like clean code; it makes the developer's lives slightly easier, but the end product is always going to suffer to some extent. Maybe the benefits gained from the DX outweigh the intrinsic costs of abstraction, but you need to be aware that trade-off is happening and a lot of people just aren't.
It's why when people say things like "inferiour packaging methods" it's a massive red flag IMO. It's indicative that they don't really understand the costs at hand. Downstream packaging is one of the biggest advantages linux has, it allows for breaking changes to be managed effectively, it allows for smaller packages overall, and it does so while still keeping true-native behaviour. Upstream packaging has it's benefits, but it also has a ton of downsides people just avoid mentioning because they seem minor individually, despite adding up fast.
Honestly I think it is a big to do about nothing.
If upstream, bottles in this case, wants to maintain a flatpack so be it.
I appreciate distros packing however as there are too many distros with too many variations in naming conventions for upstream to track. I appreciate the security in Fedora with selinux and I think it is too easy for malware to be inserted into flatpacks in general.
What bottles is doing is fine. Alert the user their package is out of date. Done.
As far as bug reports it is standard for upstream to as a first step ask the users to be using the most current package. This is the policy of every project I have ever interacted with. Just state this in the bug tracker and close bug reports referring them back to fedora or whatever version of linux a user is running.
Seems simple and a complete waste of time to have this long discussion.
I can't recommend switching to a rolling release distro enough
Frankly I'm surprised that it isn't standard practice for big distros that repackage software to always replace any support links in a software with their own.
As far as I understand, it should be the role of the package maintainer to handle bug reports for a package implementation, and escalate them to the developer if it's determined to not be the maintainers fault.
@@giusdbg idk in that situation all the maintainer has to do is filter bug requests for the developer. Obviously it's added workload I emphasize with the bottles devs. They should NEVER hear about a problem caused downstream.
And obviously if the package is unmaintained, disable submitting bugs or just ignore them.
I think Bottles is completely right, the GPL License distributes the software as is and they decided to only give support for the Flatpak version, as is their right
Not all their decisions are reasonable just like implementing electron.
@@aladdin8623 Yeah, we're not talking about other decisions though, are we?
@@aladdin8623show me where in the GPL, or any other FOSS licence, it says that the provision of NO WARRANTY has to be reasonable? My reading is that any software dev or distributor has absolute privilege to decide for themselves what is reasonable to support. It's not up to anyone else whether that's reasonable.
The anyone else who is left with an itch is, of course, free to scratch it themselves. They are just not free to put moral pressure on the devs to provide a de facto warranty to support downstream bugs.
@@trueriver1950Reasonability is a statutory limitation from the civil code.
@@aladdin8623 Why electron would not be reasonable? I myself would prefer something that is less of a resource hog, but if that is the cheapest ( in terms of time) for a great project why not?
I personally prefer distro-packaged software, but the fact that the distro packagers should add their own support links into the "about" part of the program is absolutely reasonable, and this is what every other project should do.
Once a distro packages a software, it should be on the distro to handle complaints from the users, and then if they can't fix it, they can ask upstream for help. Not every single user should go directly to upstream to report bugs. Division of labor is always more efficient.
Both approaches have their merits. In my opinion it is about choosing the right tool for the right job. In case of a complex application, like bottles, it is much better to run them in a controlled environment to minimize compatibility issues. However, if the software works nicely on its' own or needs to integrate tightly into the system, packaging them through the distro is fine, if not even required. Because this bottles seems to need this controlled environment, I cannot understand, why fedora would want to do that. It's more work for them, it runs worse and they seem already pretty familiar with flatpak (they even have their own repo). Why not just stop and use the flatpak version?!
Its just plain confusing for the user, especially when its a piece of software where having a native package doesn't have any real benefit.
Like it makes sense to have Firefox native with an option for Flatpak, but Bottles? There are only drawbacks to having the RPM version.
17:52 - "it looks like it might become more difficult, cumbersome to maintain Bottles for Fedora in the future"
This comment to me is funny as it shows that the author of the comment fundamentally misunderstands the issue. Fedora is being given the responsibility to maintain the package that they should've had originally, instead of making upstream handle the bug reports and issues. Fedora is the one hurting Bottles' image, and by proxy being anti-"the spirit of open source". If they want to be in the spirit of the community, they can follow the appropriate procedures.
I also have this issue with my software. The only official ways to install it is either from aur, flatpak or from source. NixOS is one distro that has a package for it but the package is now very old and has many issues (had issues when it was uploaded and more when gpu drivers updated). The package has never been updated. I created an issue on the nix github asking them to either update the package since it's broken or remove it but they haven't taken any action yet. Some people have emailed me asking if they should package my software for distros but I have to refuse unless they are willing to keep it up to date. This is necessary as external factors break the software (ffmpeg update, gpu driver update, pipewire, etc). This makes it so the latest version of the software is the most stable, so even "stable" distros should keep it up to date.
Update it yourself. Use an override and submit the fix when you have it, it's not that hard on NixOS
I'm a mobile software developer, to me, software packaging on Linux sounds insane, I've wondered about developing some software for Linux, but the packaging issue alone turns me completely away from the idea.
In all honesty, I think the AppImage approach has to be the best way to do this, although as a mobile dev, I might be biased. I know the project has it's issues, and more recently I've started siding more with flatpak, but I still think that the idea behind AppImage, if properly developed, would be the best way for distributing "user"/"3rd party" software across different distros.
@@tonchozhelev AppImage doesn't really solve packaging in any way. AppImages depend on some system libraries (most notably the libc) and if you want to make sure that your AppImage works on all systems then you have to build your AppImage on a very old distro, such as an old ubuntu system or old centOS. But then you cant depend on modern C/C++ features. There are also other issues. Flatpak doesn't have these issues.
@@ardishco Have you considered why I wasn't the one that created the Nix package in the first place?
@@notuxnobux I'm using the devtoolset on CentOS to release linux binaries for a modern C++ project targetting a very old distro/libc. It's not AppImage, just a binary tarball, and it locks the packaging process in to a distro, but it possible, and the binaries work on all major distros. I think this should work with AppImage as well.
Aside from targeting an old glibc, the magic is that it splits libstdc++ in two parts: the old, system/distro version, dynamically linked, and the diff between the old and new libstdc++ versions, statically linked.
Can we focus for just a second, on the simple fact this person's name is penguinpee
It's brilliant and innovative. Well done
I think people should be allowed to package third party software, but the software devs are allowed to not offer any support for those packages.
One of the biggest reasons MultiMC was originally forked as PolyMC was because the dev was hostile to packaging as anything other than deb. Since it was forked under a different name, issues with that version went to the fork's maintainers.
I like packages, they're comfy and easy to install.
To me, it seems like a majority of the issues raised by Bottles (such as outdated dependencies) are more issues with however Fedora packages software than the concept of downstream packaging itself.
I was particularly surprised by the Bottles dev suggesting Fedora version the software as - and take on fielding bug reports on their own repackage, since that's what I'm used to seeing in Debian and Garuda, and I would have never imagined Fedora wasn't already doing that.
i was a little confused by that point too, all arch packages are always -, which is used regularly to fix issues with a package if its coming from downstream rather than upstream. i feel like this is a uniquely fedora-y problem, as they seem that they dont make any adjustments for their packaging on their repos? i knew that fedora delivered pure vanilla gnome, but that they also serve pure vanilla everything, with apparently no process of delivering a special packaging seems kind of insane to me
@@zepar_ I think it has to do with a lot of new users being pushed to distros like ubuntu and fedora and those distros not doing enough to make sure those users know to report issues to them first. Not to mention the fact that these users should be aware of the pros and cons of using a stable distro. One such issue being that some packages are out of date.
@@CuteLittleMexicanMidget I know what it means, but this is literally what most other people call these distros. Google some linux tutorial or whatever and you are going to come across terms such as rolling and stable, so I am not referring to stable as in doesn't brake I am referring to stable as in "point release" because these are the terms being used in the wild.
Debian and Ubuntu often add 'debian' and 'Ubuntu' in the version info of packages, so their versions with their patches and dependencies don't get mixed up with official versions.
This isn't really about packages, it's about distro bug reporting and accountability. Fedora isn't upkeeping packages and they're passing the buck on bug reports.
I can definitely confirm that the Fedora packaging was terrible the last time I tried to use it. I wanted to compare the performance between the Fedora packaging and the flatpak, but I never could because the Fedora package failed to even create a bottle.
I also just wanted to say that I appreciate how you link to all the sources you refer to in the description.
As someone who really likes fedora, I hate how they are behaving, trying to make it seem like the bottles maintainers are against open source or some shit. Just deal with it, keep doing what you are doing if you want to so much but don't be so annoying about it.
Ironic, coming from Red Hat.
What gets me is that at the end the Fedora community does recognize maintaining such software would become complex and difficult, but they still get angry some other, smaller, project will not do it for them...
I do not understand this fedora argument. If the developers want to use flatpak for stability and less work for bugs and other issue than do that. Don't just jump onto someones else's project and package into a different formats that add more workload on the original developer and harm the people's opinion on project like bottles.
On one hand, I think Fedora should be able to do their own packaging, if there's user demand for it (which apparently there's is), OTOH - Fedora already has RPMs that are a thin wrapper that installs a flatpak, so they can do that for bottles as well.
I don't understand Bottles argument - not much software packaged for Arch. Developers control code, they can easily put message and links to official flatpack.
It's _free_ software. You can package it however you wish.
@@sergeykishprecisely, developers control code, hence they’re putting in a notification to send users after downstream packagers instead of upstream.
Bottles is making a clear argument from a technical standpoint. Wine is running Windows executables on Linux, a sandbox like what flatpak provides will give users a better peace of mind. Wine is very temperamental on dependencies, and flatpak provides tight control over versions.
The Fedora maintainer’s argument…uhm. As far as I can tell, they seem to just want Bottles to get with the program? Not sure what the discussion was like on the Fedora user forums, but remember that what users want is not always what’s best for users (and this is not a issue of freedom, it’s a issue of aptitude and security). Who’s asking for Bottles on RPM anyway? Inexperienced GUI users? GNOME Software will recommend them the flatpak by default anyway, and they’ll get a better experience. Enterprise users who don’t want upstream packaging introducing uncertainty in their systems? Then package it themselves.
@@matthewrease2376 yeah, but it should then be up to that re-packager to maintain it, and handle any bugs for those using their repackaged version. The big kicker is it seems people are bypassing them and complaining upstream when fedora is repackaging -AND- using a version that's well over a year old.
It's wild how "hey can you stop shipping broken versions of our software" is some huge ask that requires consulting with a comity and mailing list. If the upstream organization doesn't want it packaged then what in the hell are you doing going against their wishes? Why do it? Who are you serving? Especially when your version of said software doesn't even work correctly. Fedora even ships flatpak with flathub enabled these days. Total non-issue being blown out of proportion. The whole Linux machine infuriates me sometimes.
If you tell your customers you support a software, you need to provide it. If you tell your customers that they can trust the packages only contain what was in the source, and nothing malicious, you need to compile it yourself. So effectively, Fedora can either no longer give their guarantee of trust or they can no longer support bottles.
compiling software does not tell you what ti does, only reading every single line multiple times and going over it with a fine toothed comb does. @@CjqNslXUcM
“Why not listen to upstream and do exactly as they say?” Because that’s not how freedom works
@@alexnoyle Yeah bro I love having the freedom to package broken versions of software and make other people's lives harder. That shit's rad. Horray freedom.
Squash that nonsense. This is the kind of misuse of "freedom" that causes projects to adopt less permissive licenses.
@@donoteatmikezila projects make that decision all on their own. If you don’t like redistribution, you never agreed with your FOSS license to begin with.
It's just that for some software it makes more sense to package upstream, like Wine and Bottles which are infamously picky about their dependencies -and for good reason- but say something like Neovim, you're not gonna put that in a Flatpak, or FFMpeg
Exactly. WINE has needed something like this for a long time, its why things like Bottles exist in the first place. FFMPEG you tend to need to use RPMFusion anyway to get all the functionality, so its already showing the limitations of distro packages.
What baffles me is that any one wants the native one in the first place if its soo buggy on fedora i feel like most would be saying good riddance. And this is coming from some one who prefers native packages. Its like reminna on arch most of the time ill go the flatpak over the AUR package cause the AUR package just requires so many steps to get the features i need where as the flatpak just has it. So i just go flatpak
(ffmpeg absolutely has a flatpaks, btw-it's a runtime / dependency for other flatpaks like Handbrake and OBS, IIRC)
This is what package dependency is for, and what repo systems do well, except for Snap and FlatPak on average.
Wine is picking about dependencies but they use various ways to inform downstream about it and unless it's something "required" they just disable whatever feature requires that dependency and move on.
Any package not maintained by the developers should be marked as unofficial. This should be part of the licensing agreements, as users tend to believe the versions on app centers are up-to-date and the official version.
Or perhaps a new mark of "no longer maintained" invented for such packages? That would show that it was a package that used to be supported but isn't any longer. Officially included in the distro, but not officially maintained any longer.
This isn't the issue, it's that the package maintainers (Fedora/RedHat/IBM) are not handling bug reports for packages they make.
@@orbatos as I understand the discussion, at least part of the problem for the Bottles devs is that some bug reports tend to go to the Bottles team. I've deduced that from the fact that the video mentions support links actually in the Bottles package. If I'm right then that is certainly something that the Bottles devs have every cause to change.
What you suggest may well be happening _as_ _well_ of course
Aren't all packages of a distribution "unofficial"?
@@thingsiplay They're distro official, e.g. the support should come from the distro... Which is the problem. Fedora doesn't want to support packages at all, which is the actual reason for their push to Flatpak, if you missed that.
> detect non-flatpak environment
> remove the french language pack
:)
Your sick to hate french people.
@@gondorianslayer4250rm -fr /
so true beryesa (I'm beryesa and I approve of this message)
deleting the french? im in :3
Make Traditional Chinese the only language that can be used on non-flatpak environment
"more difficult/cumbersome" The way I read that it sounded like they were including more ways of telling you if the dependencies were working correctly. Which only helps packagers. They also will develop a easy and simply way to redirect support tickets, which was what he asked for.
Yea It feels like fedora was being intentionally thick-headed here. Bottles solved the issue they were talking about in a clear and concise way that allows both parties to have their cake and eat it too.
Its funny that people never realize that Podman, Distrobox, toolbox, Flatpak and even Snap are all just using Containers (even appimage works on a similar principle). They are extremely convenient and very low overhead for packages like these. I don't understand the aversion to Flatpak, especially when people who don't like them often like another containerized format. Also I am really surprised at how these Fedora packagers are behaving, they are acting like Bottle's needs to bend over backwards for them or they aren't actually open source. Its so petty. Its not upstreams job to package and fix issues for your distro. Thats so off putting.
B- b- bu-but t-th-the b-bloat!! *faints*
Containerization is a completely orthogonal problem and can be done by native packages as well. The real problem is trust difference between upstream and downstream. If you use fedora packages, you only have to trust the fedora devs. If you use flatkpak, you have to trust tens thousands of random devs that they won't put some crap into the package. It's a supply chain attack vector waiting to happen. Trust doesn't flow from single source.
I think a lot of it stems from before xdg desktop portals were stable. I hated Flatpak for a while before I realized that and the portals got improved. You had to manually edit the sandbox before that. Flatseal helped a lot, but now I hardly even need to touch it and the portals pretty much handle everything in the background transparently.
@@ayaya-ayayaBut the packaging process isn't robust enough to prevent any of this.
How does someone use podman and not realise it's containers? That's like if someone didn't realise they use containers when using docker.
This is the most polite flame war I've seen in a long time 😂
I think Bottles' compromise of an alert and removing support links is perfectly reasonable. It's up to them to decide what they want to support, and if someone wants to repackage it anyway, it's only fair that they get the tickets it may spawn.
Ah yes, not wanting to package something in a way which causes the developers a ton of wasted time means they want to move to a non-foss license. How someone can say things like this in good faith when reading what the bottles devs said is honestly astounding.
A trademark is a form of copyright
@@alexnoyleonly by some kind of analogy. In law they are different, and this is important for software like Firefox which can be tweaked and re-released under a different name (as IceWeasel for example) but can only be called Firefox if it's clean built with no code mods.
That seems to me perfectly consistent with the FOSS model: Firefox is protected against loss of face due to other people introducing modifications, but without preventing those mods happening.
In contrast this can be abused: many of us including me think that RHEL has recently taken this outside the spirit of FOSS, but that's another discussion (and another set of videos on this channel, if you haven't seen them) (unsolicited plug)
@@trueriver1950 I prefer the parent project to be licensed like IceWeasel in the first place. Rather than downstream having to remove trademarks manually. Albus Luna is to pale moon as IceWeasel is to Firefox. If Moonchild/Mozilla didn’t have a stick up their ass those projects wouldn’t need to exist.
@@alexnoyle FOSS licenses rely on copyright too. They give you the right to copy (i.e. the copyright) not negate the existence of it
@@marcogenovesi8570 I use the unlicense wherever I can, the public domain is a rejection of copyright
Imho, the Bottles team are reasonable in their request/demand that upstream shouldn't have to deal with problems caused and solved downstream. I personally won't be using Bottles anymore if there's no native solution though because for equally personal reasons I do not use flatpak or snap package management (and that's not a dig at anybody; I genuinely just don't/can't use flatpaks or snaps)
The other solution would be that Bottles could trademark their name (which would be appropriate as Bottles would be the source of goods, rather than the actual goods - meaning the software). Downstream packagers could not call it Bottles, but they could package the source as they wish since the source is still FOSS. This would be no different than RHEL vs. Rocky vs. Alma (with regards to trademark) but obviously very different with regards to abiding by FOSS principles.
Not necessarily, this is what Firefox does and in there case downstream packages can exist they just have to be clean unmodified builds
@BrodieRobertson My point is that with a trademark on the name, the Bottles maintainers could specify who can call it that (only flatpak or whatever other criteria they wish). Incompatible or unsupported downstream packages would have to use a different name.
@@r2db for sure, I'm just saying it's not inherently the case
@@r2db imagine them making packers use the name "cans" for unsupported downstream packages.
The splash screen message could be like "Don't be a bum, enjoy wine in bottles instead of cans" 😀
@@DasIllu If it is a trademark, I am not sure that they can dictate what people can call it, but they definitely can dictate what people can't call it (specifically, the trademarked name and use of the trade dress). It is no different than someone coming up with a dark-colored soda that is nearly identical to a certain major brand. The marketer can call it whatever they wish, so long as it is not confused for the major brand. They can use any colors or designs on the can/ bottle except for the trade dress of the major brand.
If it is a copyright, which would likely be incompatible with the current licensing and almost all generic FOSS licensing, then there would be more granular control. However, that would likely be a step too far as the maintainers are dedicated to FOSS principles, and it would be inherently more restrictive than necessary to accomplish the goal.
I basically universally prefer downstream distro-specific packages, and my skin crawled a little bit with the distinction drawn between "official" and "unofficial" distribution methods (as though there's something less than pure about downstream distribution).
That being said, the compromise that Bottles provided were super reasonable. It was also rediculous to say that their compromise is "against the spirit of FOSS"
@@giusdbgIf one's claiming that they're against the spirit of FOSS, then yea, I think that's kinda silly and I think that's kinda inaccurate. I don't use Wayland or Systemd personally, but these projects aren't antagonistic to FOSS itself. I can see why one might not be happy about their ubiquity in the Linux ecosystem, though. I personally don't really feel that strongly about them, though
@@giusdbg To clarify, this is all prerequisite on the understanding that the ability to redistribute software is not in actuality being hindered. If it were, then this would not be in the spirit of FOSS
Not sure how Flatpack images are build, but I'm assuming is similar to Dockerfiles on docker.
In this case, Fedora just would have to stop releasing the rpm version and just use a flatpack. TO avoid problems, they just can re-use the original Flatpack "recipe", and built it themselves with all the security checks and updates they want.
We in the bussiness do this with every 3rd party software, we don't just use the binary docker image, we download the building code, review, check and built our own verified version and distrubute it internally.
Same concept could be use by Distros, most of the time we just have to change some configuration to adapt to our systems better, or just pass it to a security checker to be sure all is OK.
0 extra work for the upstream, and a lot easier life for maintainers.
this is a good solution.
If you produce Free Software, you have to make it abundantly clear how to compile your stuff. If you use “customized dependencies” that themselves are also free software, you should provide their source and build instructions as well.
And of course Fedora packagers should be on top of their game when packaging software, and make it abundantly clear that they are the ones to whom bugreports have to be addressed to.
and then you get distros which actively (and consciously) pull out the rug from underneath your app and give them an older version than you support (and patch it so that it compiles and barely "works"), leading to REALLY interesting bug reports
The Fedora packagers seem to be stuck between a rock and a hard place. Their users want a distro package (for some reason), but maintaining such a package appears to be a demanding and draining task.
However, I'm not sure a simple take is the right answer here. Wine absolutely is fragile, and it seems nobody trusts distros to package it correctly But why is wine so fragile? Why can wine not be made more resilient, and easier to package? Why does Bottles have to package such specific versions of their dependencies? How many users want a distro package for bottles, and why?
idk, man. Life is strange.
wasn't flatpak created specifically so that devs don't have to deal with dependencies on yourmama linux 3000 or something?
That's for sure part of the reason
For general Linux software I'd say that downstream packages are good for ensuring that they all play nicely with the system, like what Fedora's packagers were arguing for.
Which is ideal for pre-installed software that should just work as expected on a distro.
But when it is explicitly user installed software that needs more updates, like Bottles or for example a web-browser, it's better to have the user install the upstream packages.
Though with web-browsers especially can it be better to have an intermediate packaging step, like the many Chromium flavours or LibreWolf and similar.
This for cases where the original developer can not be fully trusted to deliver the project in an optimal state for use.
Which goes the other way for bottles, where Fedora's maintainers evidently have proven to be the problematic side.
So in short, as almost always, it depends.
I've never had a problem with using web browsers from the distro package, but I absolutely also see merit in having the flatpak option too.
Bottles or anything WINE related, its been nothing but trouble so I'd much rather distros not include them at this point as its clear they cannot keep up with the speed of development and dependency changes.
@@alexatkinWhat the heck? Why are you including wine? Wine has been fine for *decades* as it has been winetricks. Leave those alone.
This was very informative and interesting, thank you. This and things like theming continue upstream's revolt against downstream.
And additional thanks for having the most important, best explained Linux channel for us Linux normies out here. Early congrats on what is soon to be a well deserved 60k subs!
I personally agree with everything Bottles did and is saying EXCEPT for removing the package from the AUR. I don't care if newbies from Manjaro are causing the issue, that's (one of) Manjaro's (many) problem(s). And you shouldn't be using the AUR unless you're experienced with Linux anyway.
I'm not saying the Bottles developers are wrong with the Fedora clusterf**k, but stopping the AUR package actually grinds my gears.
Especially because while I do like using Flatpaks, sometimes, you just want to have a native package.
I do agree here i feel like the ui prompt of this being a non official method is already a great solve with this. I also hate this rush to everything should be a flatpak. Theyre great and sometimes solve issues theyre sooo freaking heavy. Why not use something similar to what python did with py env and just package apps to call to versions of programs that can run in a dedicated virtual env that can be as sandboxed as flatpaks while not being as heavy as flatpaks
Downstream packaging is what brought us the entire just use one package manager for all with a certain security guarantee philosophy and should absolutely be continued.
(Flatpak does try to solve some of these issues, but it certainly isn't perfect, more than often packages are shipped with semi or even fully broken permissions, which for users new to flatpak might seem like it just doesn't work. Or the fact that flatpak just simply doesn't integrate well, or in some cases at all into your desktop (once again, at least without specific user changes))
Projects are ofc, within their rights to do all of what bottles does, especially since they do use dependencies that might not be feasible to package for a regular distro.
The only thing I would not like to see is a move towards non-free licenses in order to achieve this, but this is clearly not what happened here.
For me, I have no problem in people repackaging my software but dont point them to my project's github page when there is a problem, that's all I'm going to ask since I believe in the spirit of FOSS but I also believe in taking responsibility for your own work....
In this case, the maintainers didn't point users towards the upstream. Upstream itself did that. In the "Hamburger > About, there is a "Report an Issue" link that directly links towards upstream. Upstream could make that link customizable at build time, such that if you don't provide any link, no such option appear.
what I think is that I should distro hop to either OpenSuse or NixOS, because it seems fedora is being run by jackasses who purposefully misread people's comments.
Bottle devs: the majority of issue reports in our issue tracker are done from fedora rpm, can you stop packaging it like crap ? or at least have an issue tracker for yourselves ?
Fedora devs: sO yOu DoN't LiKe OpEn SoUrCe ?
like, what the hell ? are you guys really devs ? or 5 years old kids in trench coats ? It's embarrassing using an OS from those people.
The fact that once they made it so fedora actually had to deal with the fallout of their packaging problems, their only comeback was a vague insult like "you are moving into a proprietary direction" feels telling.
The spirit of open source is not, in fact, that you can single-handedly cause high support-traffic and bad user impressions for other developers and then let them deal with the aftermath.
Certaily a balance to be struck here. The bottles project has every right not to support downstream packaging.
Clearly not enough is being done to teach new users to report packages to their distro first.
Some software simply isn't meant for stable distros. Users of said distros in theory should be used to out of date packages by now.
Now with all that said, I do still think there is value in distros maintaining packages. They are most of the time far better at it than anyone else in my opinion. There are many other benefits, but don't wanna go into all that here.
Lastly, while there are a bunch of benefits as well as downsides to containerized solutions. I can't help but feel that if that is the only way your software can run. There were some bad design decisions made along the way. There are exceptions and I think this is one of them, but they are not the rule.
"Some software simply isn't meant for stable distros. Users of said distros in theory should be used to out of date packages by now." I think it comes down some software refusing a stable maintenance model or it's to early for the program. Using unstable libraries that are not meant for production is a no no in any package environment.
@ Looks like my last comment got removed for posting the xkcd 927. Anyways, I was trying to say that I agree that developers have some responsibility in the matter. I just didn't know how to word it.
Not disagreeing with you there, just wanted to say that these developers might involve practices that the upstream of the downstream they are because they use their libraries might not like they behavior either.
The GPL has always included, in shouty caps, that the software comes without warranty. That includes that the folk who produce that package don't have to maintain it at all. That means they have the discretion to decide which environments they choose to support and don't support.
Bottles is absolutely within the spirit of the GPL to say that they will notify users of their software that the support they provide is only available for approved environments.
Bottles is absolutely within their rights to automate that lack of support of they choose to do so.
I've based this answer on the GPL but, in my sense of what FOSS means it applies to any other licence that I would regards as a FOSS one. Many of the other licences also include similar disclaimers.
It makes sense: you don't take on an unlimited duty to the entire universe when you give something away for nothing.
Fedora are referring a moral pressure that doesn't actually exist when you look at their position and the various open source licences.
Fedora aslo doesn't have to do shit all for them in that way of thinking
@@nicfit23 true but it totally missed the point. Nobody is saying Fedora should do anything.
What's being said is that Fedora should stop the moral blackmail entailed in their claim that Bothers is somehow anti the spirit of open software.
I agree with that feeling - it's that moral high ground by FEDORA that's objectionable.
I don't really understand the drama in here. The upstream packager refusing to support downstream packages in projects with a huge amount of finicky dependencies is nothing new. (Ardour does this for example)
I was about to comment that "If this is such an issue create a dialog box on startup to communicate about the flatpak version being the only supported option from the main developers and turn the distro package users to their respective packagers". And if I understood correctly this is pretty much what happened and even bit more elegantly than that.
OSS is all about giving freedom to share the code, binaries and ability to for others to pick up the development if needed. A requirement to give mandatory support is not part of the deal.
The sensible option would be to make an issue template with a checklist "I used the version installed from ". If the checkbox is unchecked, you close the ticket. Or you can require packagers to change the version string to something like 4.1.1-fedora. If the bug ticket doesn't list the version or its not what you expect, you just close the ticket. No need for drama here and it's not a new problem.
@@ayaya-ayaya it's not just about the extra github issues though. The devs have said new people keep trying Bottles as a native package, keep having a bad experience and form a bad opinion right there because regular users pay almost no attention what kind of package they're running. And soon word of mouth will be that Bottles is a buggy project when it really is much better in a predictable environment without anyone ever going to github to write something
@@iodreamify I forgot to mention the trademark. I don't know if Bottles is already registered. If not, then it's too late. Otherwise they should just restrict the usage of their trademark only to official packages. Once again a solved problem.
The positive thing about this Fedora mess, was that the voice of the end user was heard. The end user has spoken and he wants a functioning repo package and no stinking flatpak. Its up to Fedora to invest time and manpower to provide just that. A distro that can't provide repo packages is useless and should be abandoned.
I think Bottles has a reasonable point/request with no real issue that I could see, not sure why Fedora felt the need to push back.
What makes this really WTF man, is that I thought Fedora was moving to a policy of Flatpak first to start retiring all RPMs that aren't core to the system for GUI apps. Figured having one that is built for Flatpak would be a plus for them. I know they were going this with LibreOffice.
Whatever happened with the distributions, you know, *distributing* software? Why would Fedora be discouraged from packaging? It's literally their job.
They shouldve just trademarkered their name and then pulled a mozilla
If upstream continues to get spammed by packaging issues, that model might become more popular
A long time ago, Arch built their Firefox packages with the "branding switch" turned off. Maybe these kind of upstream-versus-distro disputes could be avoided if the "branding switch" concept were to become more commonplace (i.e. present in more applications and turned off by distros more often).
(I'm not sure whether Firefox still supports the "branding switch", though Wikipedia claims that it does. It was/is a compile-time option that, when turned off, would make the window title bar display the version-specific codename -- such as "Deer Park", "Bon Echo", "Gran Paradiso", etc. -- instead of the name "Firefox" and also would replace the normal Firefox icon with a generic plain blue globe icon.)
@@The_Lawnmower_Man im pretty sure it still support that but instead you have to provide your own branding iirc
I think upstream and downstream package both server necessary purposes, it really depends on the specific application. (course if you're dependency tree is shaky and unstable, this demonstrates the perfect case when not sticking to upstream is a nightmare)
If they offer a Flatpak that should be the ONLY supported install method, Flatpak was/is meant to be the future after all... This discussion also feels a little like the whole Wayland/Xorg thing in reverse. Surely we all should be pushing for Flatpaks to be used 'when available' as imo it makes bug reporting easier and more direct (although it sometimes make it harders to pin the actual problem down). The bottles guys here are spot on, if you want to redistribute a package in the format you want then ALL the problems it causes should be sent to the package maintainer first, if you don't want the responsibility then all you have to do is tell users to use the 'official' flatpak.
It's more nuanced than that. Flatpak isn't a clean Solve to packaging as a whole. Flatpaks are heavier than native and as a person who strongly prefers native packages. i personally advocate for an approach similar to what pythons done with pip already with py env. Package apps in a way where they will include a call for a specific version of a dependencies over the past 3 versions to give a arbitrary number here. This solves the dependency issues and by creating a v env at run prevents system breakage which can accomplish the same security goals as flatpak . Flatpaks are great for so.e things but theyre not for everything. Ill take them over snaps and app images, but in most cases, i still prefer native to flatpak
Having said this im on bottles side here bottles is a strongly complex app you shouldnt package it for native without making it your problem to solve all issues in your packaging issues
I fully agree with the Bottles developers. I always found the classic software packaging approach on Linux insane for most end-user software.
The bottles developers could change their trademark policy to say you can't use the name Bottles for downstream packages. Distros could still fork and/or repackage under a different name, similar to how debian shipped Iceweasel as a replacement for Mozilla Firefox due to trademark disputes. I think it would help communicate to users that the bottles devs don't want bug reports from "jars" or whatever the downstream package is called.
I think the comment by penguinpee was not a message that should be written by a package manager maintainer....
Yeah it is FOSS, but it is exactly why you need to take respect each other else you could kill the motivation of some maintainers to keep the project running, which is in a way the worst case scenario :/
Also forcing an external bug system onto project maintainer is not a good idea....
So respect the project that you include in your environment, and I totally agree with the "you repackage it, you maintain it" thinking because the original maintainer is not in control of dependenciesm and it can break your system, remember system86 desktop environment and the steam using incompatible version of a lib (which linus tech tips, covered involontarely)
And once I had to install an old package, it downgraded most of my package which were its depedency removing my display manager....
And I'm not taking into account package which were fixed years ago but were not updated, like kde-settings which segfaulted in kubuntu but was fixed a year and a half ago....
I think that native package managers should just be used for few things, and most things should be in flatpak.
most apps are on flatpak and it reduces the workload on the developers.
Maybe this is a hot take, but I think the maintainers/creator/whatever should trademark their brand while keeping the source-code FOSS. That should make the problem go away, if the downstream doesn't want to maintain it, just send a claim to stop using the brand. The distro would be obligated to stop distributing it, or start distributing under a different name.
I mean, if you were to ask Mozilla Corp. they'd say that's the complete opposite of a bad take... as that's literally how they treat their own 'babies', such as Firefox, etc.
Funnily enough, that's why downstream RHEL distros like (formerly) CentOS, AlmaLinux, & Rocky Linux and the other ones could use the source code but couldn't use Red Hat's trademarks. Guess who Fedora is funded by?
That's right; Red Hat!
But if they don't enforce that trademark with everyone, they could have it taken away.
I'm not up to date with all package formats, but has any of them come up with "Versioned Dependencies". This would mean that multiple versions of deps/packages could be installed AT THE SYSTEM LEVEL, other packages would use the version they require.
This would be like halfway house between flatpacks and system install. A package@version could be shared amongst other packages/apps reducing the need for enourmous flatpacks and not overwriting a particular version of a dependency.
I realise that not all situations could have multiple versions installed, such as when interfacing with hardware etc. But that would also apply to flatpacks and the like.
Of course it must be that no differences exist between any package with the same version info.
Maybe packaged by each project team and supplied / made available to distros, rather than packaged by the distro.
This might solve arguments between distros and package suppliers. Also cut down on work repetition.
You could even have a "uplift dependencies" function, where an existing package/app could try and use newer depenencies so older deps could be removed from the system. If there are proplems, the package/app could revert to "tested" dependencies, with the os reinstalling them if neccesary.
As for sandboxing, should be done by os containers.
This would be mainly controlled by a package descriptor file (for each package), the "Tested Deps" section never changing.
I've seen package/apps = < 100mb for system install, flatpack = > 1 GB.
Would be nice if all distros could use 1 package format that catered for all needs.
Any comments, does any package manager / format already do this ?
I like bottles solution. If you package it you hade to point ass support solutions to you (doing more work) or the program displays it is unofficially packaged.
I disagree. Bottles has no obligation to provide support for distro packages but to actively work against them is bad for the ecosystem as a whole. Centralizing development also means there's centralized control over the source, which is kind of the same stance Mozilla took with Firefox in Debian (which Debian had to rebrand as Iceweasel after Mozilla insisted Firefox could not have any distro specific patches applied to it whatsoever).
Just imagine of Google had the same approach to the Chromium source code. We would be stuck with Manifest v3 making ad blockers virtually impossible, Privacy Sandbox would be mandatory, etc. It's an awful idea no matter how well the Bottle devs intentions are.
If Bottles devs don't want to have issues related to downstream versions then all they have to do is to make that clear in their issue template. This works fairly well for a lot of other projects and I don't see why Bottles would justify being a special case.
Totally agree with the bottles dev team, just last week I tried the fc38 bottles package.. total disaster ,so I uninstalled and went with the flatpak and presto works like a charm
The entitlement of the Fedora people gives me digust shivers.
You cannot just be like "I want this unofficial thing to be a thing and then dump a bunch of work and issues onto the creators of the software without their consent, and if they don't take this without a fight, I will call them open source enemies"
This whole packaging business is a good part of why windows continues and will continue to hold significant market margin. It's not fair but the convenience of daddy microsoft is dangerously tempting.
TBH I prefer a native package sandboxing in flatpak adds too much complexity IMO.. only a few apps I run in flatpak as not much an issue but have found running wine based stuff to be stupid af in flatpak in regards to gaming because as it stood the last time I used Lutris or Bottles in a flatpak if you had your controller turned on starting it up it worked.. as soon as it turned off it will no longer work in said game without a restart.. no thank you
So the funny thing about relying on flatpak is that in my experience flatpak apps tend to be... kinda wonky.
Like if you don't use GNOME everything ends up with weirdly glitched out fonts, and not respecting any theme or color schemes, shit just looks like flashbang amongst all my dark themed normalcy
Personally, whilst Bottles is in the right to be pissed that all the issues keeps getting throwed to them, Bottles doesnt have the right to criticise and argue to package managers doing the packaging - especially when they refuse to help
Fedora side should learn a thing or two about pragmatism, or just basic empathy.
Would _they_ act the same if it was their software being, for lack of a better term, misrepresented?
@@giusdbg Christ on the cob. Do I have to write comments while specifying to the point of including timezones or something?
Let me broad. Is it so hard to just get that I don't mean the entire Fedora project? Come on now, neither of us is that dense
@@giusdbg Not my fault your ears, and seemingly-You know what, no. I'm done
I like the idea of upstream packaging, but I hate containerized software on the desktop, it just makes everything more complicated.
i prefer downstream packaging and "traditional" package management, at least, i used to. moreover, while it wasn't one of the reasons i switched to linux, it was one of the reasons i liked it more than windows, it's just easier to manage for me as a user/admin. that said, i don't really understand why would that person play the gpl card, really. like, iirc, gpl doens't oblige anyone to support even what they distribute themselves, let alone what somebody else does. moreover, i think it would make sense to encourage other devs to have blanks for support/bug report links in their about page for distros to fill in, if they package that software
Sounds exactly like the situation MultiMC had which led to the fork known as Polymc. They didn't want others to use the same branding with different packaging standard. I honestly thought Fedora users would be more accepting of Flatpak considering it ships with it.
It also sounds a lot like the XScreenSaver upstream-versus-Debian dispute from back in 2016, a.k.a. Debian bug report 819703.
(Quick explanation: XScreenSaver's upstream developer had added some warning messages -- one of which in part said " _If this is the latest version that your distro ships, then your distro is doing you a disservice. Build from source._ " -- that would appear only if more than 1.5 years had passed since the running version's release date. He claimed that this was done in response to having gotten too many emails from end-users about long-since-fixed bugs.)
Very ironic considering the official flatpak version is the only one that consistently does not work correctly. Running wine prefixes in an additional sandbox environment is so stupid. So many times games just can't seem to access the correct system hooks or variables when run under flatpak
This is an interesting scenario. Can you point towards issues raised about this?
True, I had to manually give Bottles permission to access my home folder, because by default, the Flatpak does not even have read access, making it impossible to run or load anything that is not inside the .var Bottles folder.
I've always had the impression that Lutris is a much better solution for running Windows programs; I never had this sort of issue (neither with their Flatpak nor with the distro-provided package) and, guess what, they don't get into fights with package maintainers. They do their jobs, and let others do theirs.
Fedora should accept that the only good way to provide packages are from the devs. Imagine if they decide to change the package as they do with mesa, ffmpeg and others. I need use a static ffmpeg version to have more features that distro packagers don't want to provide.
In an ideal world: I like the Debian model. Debian is known for having "obsolete" packages. The policy is: bugfixes only between major releases. The issue is that most upstream projects refuse to support such old releases. If you find a bug in a Debian "stable" package: the first thing the upstream developer does is to tell you to reproduce the bug with the latest release.
But If I wanted bleeding edge: I would run a rolling release distro: not distros based on Debian.
debian maintainers: "hold my beer"
"we don't fix this crash in stable. switch to testing"
Good. One less bit of package management fragmentation I have to deal with.
I remember some issues with flatpak sandboxing on bottles in the past, but for the most part using the AUR version works fine for me on Arch, that being said while I prefer bottles over Lutris it still is not that great in use.
Yeah. I do think the AUR version should still be maintained, but I agree with the Bottles developers on the Fedora issue; at least Arch is a bleeding edge rolling release distro, so it doesn't have Fedora's older packages problems.
@@cameronbosch1213 I will say that it took me a while to remember the problem with the flatpak and that was the pain it takes to get mangohud working in it, however it seems they resolved that a year ago, so maybe I will switch to the flatpak.
Distros should focus on providing an operating system, not an app store. You should have system tools, a DE (or multiple), also things like a browser and basic tools, but packaging an office suite? *Why*, what's the actual value you could add to that. At least if you're not NixOS: Nix packages are in a sense flatpacks on steroids, not caring on which distro they run on. Running on other distros is an underused feature and I kinda consider flatpack, etc, as being NIH software, the solution already existed when those came out. That is, the flatpack devs should have focussed on building an app store, not a package manager...
Hearing anything about the FOSS Spirit/Philosophy coming from Fedora Maintainers has a bit of a stale aftertaste as of late, imho.
And in general, the Fedora guys come off as "my problems are your problems now, deal with it" and that's hurting FOSS in general. People might just stop developing awesome ideas because they get screwed over by over entitled maintainers.
I don't like Flatpaks, but I agree with Bottles on the issue.
Is this one of those :"Stop what you are doing, so I have less work and you also have less work"
And the other side is: "No, our way is better where we have to deal with more work that you could spare is, it is better this way, no extra confusion for anyone.
Does remind me of some of my coworkers.
I'm a Fedora user and am completely on Bottles side
If the downstream maintainers weren't doing such a poor job the upstream would not need to have this discussion. In a perfect world yeah having distro packages is "better", but do you actually have the manpower for it? Does it matter that much for that specific application?
For Bottles it's a huge pita and given what's its main purpose you are not going to feel even a few GB of additional flatpak runtimes.
This reminds me of that dispute between jzw and Debian some years ago, around XScreenSaver.
Debian packaged an old version (apparently backporting security patches), jzw received bug reports for things that were already solved (while also accusing Debian of shipping insecure software), jzw put a "time bomb" in the code, people complained about that... there were a lot of back and forth, and lots heated comments.
Both sides have good reasons for wanting to do things one way or the other.
You missed one of the best comments
"I can't stress enough that you force volunteers to support the fallout of your package's shortcomings"
5:07 How does anyone suggest learning more about how packages work? Every time I try to research packages I get the same bland introductory stuff about what a package is, but it seems like a deeper understanding could often come in handy. It gets even harder with specific stuff like how ebuild works.
It's quite simple I guess, the best way to package an application is one where the original source code can be used as is without the need for any patches to make it work. Fedora obviously hasn't been able to make it work, so they should just listen to the Bottles devs and retire the RPM package.
I am not sure whether Flathub has replaced the Fedora flatpak repository in the immutable Fedora variants, but it's surprising to see a Fedora maintainer push for a native package when their distro itself is driving Flatpak adoption.
bottles is correct, simple as that. if fedora wants a package, wrap the flatpak in an rpm. done.
Bottles really seem like a group of people trying to do things right.
I 100% agree with bottles - there are so many people clenching onto traditional packaging formats despite their challenges. Packaging and dependency hell has been a problem on Linux for years which is stagnating adoption. No Dev wants to take bug reports for a package on every distro. It's time to say goodbye to the RPM. I know this format will be used for decades to come. But it's time to start pushing for the end.
Bottles is doing the right thing. They're not changing the license or stopping Fedora from creating a patchset of any kind so this seems like a non-issue.
I like downstream packaging. Distro maintainers pick a version and package it for their release cycle. If there are bugs, they fix them, but new features would come through an upgrade when upgrading to the next distro release. I think the problem here is that at that point, bottles was not that evolved yet and had a few bugs in it. Maybe if they were not game changing fedora chose to stay on the version to not get random ui/api changes mid-cycle, because fedora wants to have some stability (it's not a rolling distro). But of course they could have fixed the bugs themselves, which would require some work.
Also, with having rpms instead of flatpaks you can do some more things, like building your own docker containers with it without having a flatpak-in-docker situation. And for people running it on the host the package is smaller and much better integrated with the system and the other applications and can use shared libraries like they are supposed to
The problem is distro packaging is based on SHARED dependencies, from the legacy of needing to keep duplication down to save storage space. This plain doesn't work when a project is making changes to those dependencies regularly and needs to build against its specific versions to work properly.
@@alexatkinExcept when you have a security issue with a private dependency and suddenly you are updating 50+ different upstream provided packages that don't all do it at the same time. Saving space wasn't the only reason to have shared libraries.
I'm involved in another project that relies on wine (specifically, I maintain the flatpak for that project), and so I know how picky wine can be about the environment it's given. This decision by the bottles team is completely reasonable and I'd probably make the same decision if I was in their position.
while fedora is free to package software as they see fit, it is absolutely within bottles gpl rights to distribute their software as is
fedora basically forks and re-distributes if they don't package as flatpak, which is how the original software is provided, so the issues are theirs
While we have containerised apps, I don't think we need distro's to package their own apps. Just link the appropriate repos, and let the original developers handle it. This opens up time, and resources to the distro's developers to work on their actual distro, and other projects. While I like and use Fedora, the Bottles creators and completely in the right here.
Letting the upstream handle it would put us in circular dependency hell, where nothing works and everything works, but only for the upstream.
tbh the bottles fedora package worked a lot better for me than the flatpak, for some reason...
more features and more games "just run" when i installed...
Also the flatpak version couldnt find my steam to put the games there while the fedora could...
For example: alan wake would not open in the flatpak version, but in the fedora it just worked.
I don’t see a problem with a developer having an opinion on how their software should be packaged. They can’t force others to package it that way but the bottles devs never came at it from an entitled way. I think they probably should have STARTED with the UI update the moment fedora said they were still going to package it themselves as that is the proper solution, but hey they got there eventually.
I do not agree with fedora getting all salty about it and clearly not making an effort to understand their argument. They clearly had a very good technical reason for wanting their project packaged in a specific way and I certainly do not think it means they are against open source. The standard packaging model works for a great number of things, but wine is ALWAYS a pain.
Now I am waiting for the fedora packagers to point to the bottles repo for support in their build cause with how this conversion went down I wouldn’t be surprised if they just decided to ignore the bottles devs wishes some more.
With all due respect, the video is interesting, but I had to go to the original sources to understand what the issue was about, as you launched in the conversation without much context imho.
Things started to make sense after a few minutes, but by then I had already read enough to make the video redundant...
I do wonder if the Bottles team could gaslight package managers by making the Bottles program part of a runtime environment, kinda like what Steam does. Probably impossible given the complexity but it is an intriguing thought.
You shouldn't be able to stop third parties from packaging your app, but if a third party messes up, it's not up to you to fix that.
Allow third parties to do whatever and let third parties handle support for their own work. That's why official packages exist. To differentiate
I'm with Bottles here. Too many moderately or more complex apps get completely neutered by downstream
To be honest if mozilla and ubuntu can force the user to use the snap version why bottle couldn't make the same with flatpak?
We all have to wake up in the Linux community. Downstream packaging in theory should have reduced the load on the developers having to distribute their software. But in practice unless you are building hyperstable library/app like Xorg or or sshd but instead develop a more useefacing modern application where a button being a bit much to the left has to fixed in a matter of months at most, it actually makes it harder for developers to keep up with all the package managers.
If we really want to see a year of the Linux desktop happen, we need to embrace developer driven packaging much more. Not every software is FOSS either (sadly, but it do be like that sometimes) And these applications will not have the patience to deal with maintainers' mailing lists.
Let's just all agree on some developer driven packaging for developers that dont want to deal with every single distro maintainer individually. (What a such unreasonable thing right? /s)