I’m not a dev exactly. But I got my Linux skills using Slackware and I still have no problem compiling something if there is no package for it. In some cases I will use a appimage(Cura) but for the most part I just install natively. I use ubuntu but always start eliminating snaps on any install and it really doesn’t take that long.
It’s about predictable troubleshooting for a bug, not about whether you can install it. No doubt you can, but now the dev has to figure out what particular feature in your OS is causing the issue.
I had this recently, installed Distrobox, which is just a set of scripts, on Aurora. Could not --clone a container, no how. Blow the OS out and install Fedora 41 which is what Aurora is derived from except it’s rpm-ostree, and not a problem cloning a Distrobox. Closed the bug as there was no point trying to figure out what went on there for some weird edge case of using a specific distro.
Aren’t you at all curious why it failed though? (If not, no harm no foul – I certainly know time diagnosing a bug is always in short supply, from personal experience). What if it’s a symptom of something important that might happen later even in Fedora 41?
Sometimes it just feels like containers are used as justification for devs to blow off bug reports. As a dev I want to understand why a failure occurs.
I’m curious enough, but this seemed like it was going to be hard to track down a way to fix it, and I needed that laptop working for other things, and Aurora was being really flakey in other ways as well so I just nuked it.
I’m happy to burn time debugging an issue for a project, but when I tried to track down a way to bugreport to Aurora, I didn’t find anything easily. And this promised to turn into a fingerpointing issue, so I moved on.
I’m not a dev exactly. But I got my Linux skills using Slackware and I still have no problem compiling something if there is no package for it. In some cases I will use a appimage(Cura) but for the most part I just install natively. I use ubuntu but always start eliminating snaps on any install and it really doesn’t take that long.
It’s about predictable troubleshooting for a bug, not about whether you can install it. No doubt you can, but now the dev has to figure out what particular feature in your OS is causing the issue.
I had this recently, installed Distrobox, which is just a set of scripts, on Aurora. Could not --clone a container, no how. Blow the OS out and install Fedora 41 which is what Aurora is derived from except it’s rpm-ostree, and not a problem cloning a Distrobox. Closed the bug as there was no point trying to figure out what went on there for some weird edge case of using a specific distro.
Aren’t you at all curious why it failed though? (If not, no harm no foul – I certainly know time diagnosing a bug is always in short supply, from personal experience). What if it’s a symptom of something important that might happen later even in Fedora 41?
Sometimes it just feels like containers are used as justification for devs to blow off bug reports. As a dev I want to understand why a failure occurs.
I’m curious enough, but this seemed like it was going to be hard to track down a way to fix it, and I needed that laptop working for other things, and Aurora was being really flakey in other ways as well so I just nuked it.
I’m happy to burn time debugging an issue for a project, but when I tried to track down a way to bugreport to Aurora, I didn’t find anything easily. And this promised to turn into a fingerpointing issue, so I moved on.