Hmm... So, requiring a [sandbox](https://github.com/bottlesdevs/Bottles/pull/3583) to run @usebottles@mastodon.online is considered evil and proprietary software, but [patching it to remove the donate button without updating support links](https://build.opensuse.org/projects/openSUSE:Factory/packages/Bottles/files/dont-support.patch?expand=1) is considered fine? Uh huh...
There is an entire post from the devs on why Bottles is packaged the way it is. [https://usebottles.com/posts/2022-06-07-an-open-letter/]. If you put yourself in the developers’ position, it’s actually understandable. Distributions ship Bottles package filled with issues or straight up borked, users turn their frustrations to the Bottles developers instead of package maintainers, devs get frustrated and bombarded with issues that they can’t fixed. A ton of time, effort and mental health is wasted. I think the wishes of devs should be respected, even though the software is open source and you CAN package it however you’d like.
Actively resisting packaging is not the way, tho. You can just require an issue to be reproducible with flatpak, and otherwise tell ppl to bother the maintainer.
So, basically, you make software that doesn’t work outside flatpak without patches, then start removed about how much those patches suck, then, instead of pretty much saying “we only support flapaks, stop bothering us with distro-related issues” on the issue page, you add even more stuff that needs to be patched out because “sesurity”? Makes perfect sense, ngl.
I don’t think it’s understandable in this case, no.
The entire project depends on Wine, imagine if Wine devs restricted Bottles in what way they are allowed to use it just because Wine project doesn’t want to deal with bugs potentially introduced by the Bottles dev.
But they won’t, because of the license.
And neither can the Bottles devs.
If they want to have total control over their source code, fine, but then they cannot claim to be open-source and release it under GPL.
just because Wine project doesn’t want to deal with bugs potentially introduced by the Bottles dev.
If you have issue with Bottles, you don’t immediately go to the Wine bug tracker. If you have issue with packaged Bottles, you immediately go to the Bottles bug tracker. There is clearly a big difference.
Yes, and another big difference is that Bottles refuses to provide any kind of help to package maintainers.
According to maintainers’ comments on the Github project, they have to figure out how to build it by trial and error.
I was actually really surprised that there’s isn’t any kind of build documentation.
It’s pretty unusual.
There is an entire post from the devs on why Bottles is packaged the way it is. [https://usebottles.com/posts/2022-06-07-an-open-letter/]. If you put yourself in the developers’ position, it’s actually understandable. Distributions ship Bottles package filled with issues or straight up borked, users turn their frustrations to the Bottles developers instead of package maintainers, devs get frustrated and bombarded with issues that they can’t fixed. A ton of time, effort and mental health is wasted. I think the wishes of devs should be respected, even though the software is open source and you CAN package it however you’d like.
Actively resisting packaging is not the way, tho. You can just require an issue to be reproducible with flatpak, and otherwise tell ppl to bother the maintainer.
That’s a lot if communication for someone that’s working for free.
That’s a disclaimer in the bug submission page.
Which everyone will ignore.
They take donations, that’s not free.
As a guy who worked in OS security, no fucking way will I be doing that.
So, basically, you make software that doesn’t work outside flatpak without patches, then start removed about how much those patches suck, then, instead of pretty much saying “we only support flapaks, stop bothering us with distro-related issues” on the issue page, you add even more stuff that needs to be patched out because “sesurity”? Makes perfect sense, ngl.
I don’t think it’s understandable in this case, no.
The entire project depends on Wine, imagine if Wine devs restricted Bottles in what way they are allowed to use it just because Wine project doesn’t want to deal with bugs potentially introduced by the Bottles dev.
But they won’t, because of the license.
And neither can the Bottles devs.
If they want to have total control over their source code, fine, but then they cannot claim to be open-source and release it under GPL.
If you have issue with Bottles, you don’t immediately go to the Wine bug tracker. If you have issue with packaged Bottles, you immediately go to the Bottles bug tracker. There is clearly a big difference.
Yes, and another big difference is that Bottles refuses to provide any kind of help to package maintainers.
According to maintainers’ comments on the Github project, they have to figure out how to build it by trial and error.
I was actually really surprised that there’s isn’t any kind of build documentation.
It’s pretty unusual.