arc99@lemmy.world 3 weeks ago
The answer for this guy and other people stretched by supporting Linux is to say it’s flatpak or nothing. Stop trying to build for each dist because it’s not sustainable. If someone on a dist wants to maintain a package then let them take the heat if it is broken.
If someone on a dist wants to maintain a package then let them take the heat if it is broken.
That’s quite literally what happened and why this guy is moaning though. Nobody asked him for an Arch build, people distribute it themselves on the AUR and he’s annoyed anyway.
Why should he get a say on how someone else installs the software on their own systems?
If I want to build an arch package instead, what business is that of his?
It’s open source, the package the developer chooses to distribute doesn’t affect your ability to create whatever kind of package for your own system you want.
Except this developer has created license terms that forbids the creation of “packages”, so he clearly does want to affect my ability to do just that.
I use the Duckstation flatpak funny enough
No, you are harassing and bullying poor Stenzek.
Typical Linux user, using Linux and stuff.
/s
Flatpak is dead, moving to appimage. Finally, an appimage that isn’t broken.
nyan@lemmy.cafe 3 weeks ago
I don’t think you quite understand how this works. No distro ever asks third party programmers to create packages for them—that’s the job of the distro’s own team, or of enthusiasts using the distro. All the distro packagers want or need from the original programmer is the source code and enough documentation to get it to compile. They take it from there.
The problem here appears to be that some people with disagreeable personalities chose to complain to upstream instead of (or in addition) to their distro or whoever provided the package. There’s nothing the distro can do to prevent that. And if you’ve been in the game for a bit, you know that, if your software gains any traction, you’re going to run into obnoxious users with entitlement issues and you need to have some way of dealing with that (mentally and procedurally). The programmer here apparently didn’t have the mental stamina to deal with obnoxious users, and threw a fit.
arc99@lemmy.world 3 weeks ago
Did you read the text? This guy was providing a package because the default one was broken and he’s fed up of dealing with complaints. And the solution to that is just flatpak the thing and tell users to use that regardless of dist.
Localhorst86@feddit.org 3 weeks ago
I don’t think we can count the AUR repository as the “default package” because:
sugar_in_your_tea@sh.itjust.works 3 weeks ago
And that’s the real fail. AUR users need to understand how things work, AUR packages are community maintained and supported. If the build fails, complain to the AUR maintainer, and they will raise the necessary bug reports to the upstream project if the bug is w/ the project instead of the build instructions.
nyan@lemmy.cafe 3 weeks ago
Providing a package, if he did so, was his choice. No one at the distro asked him to (some users may have, but that has nothing to do with the distro or its other users). If you provide the package of your own volition, you should expect that there will be complaints if it doesn’t work as expected. You need a procedure (and a certain amount of saved-up mental fortitude) to deal with them.
If someone complains to you about someone else’s buggered-up packaging job, the correct thing to do is have a prewritten reply set up saying, “Nothing to do with me, complain to the other guy.” Then close the bugs as WONTFIX and get on with your life. And see if the package host has a removal policy for broken packages, if it is genuinely broken and not just clueless users messing up.
To me, this specific case seems like the dev wasn’t prepared for what the open Internet is like, couldn’t handle it, and imploded messily. Are the users that got on his nerves at fault? Yes, on one level, but their existence was also entirely predictable. If you know what you’re doing, you factor the existence of these people in when you decide whether you’re willing to release your software to the public or not and what communication channels you should leave open.