2 ms·

This is one of the reasons I switched to RHEL 10+ years ago. I actually prefer the RHEL policy of leaving packages the way upstream packaged them, it means ups

This is one of the reasons I switched to RHEL 10+ years ago. I actually prefer the RHEL policy of leaving packages the way upstream packaged them, it means upstream docs are more accurate, I don't have to learn how my OS moves things around. One example that sticks out in memory is postgres, RHEL made no attempt to link its binaries into PATH, I can do that myself with ansible. Another annoying example that sticks out in Debian was how they create admin accounts in mysql, or how apt replaces one server software with another just because they both use the same port. I want more control over what happens, Debian takes away control and attempts to think for me which is not appreciated in server context. It swings both ways too, right now Fedora is annoying me with its nano-default-editor package. Meaning I have to first uninstall this meta package and then install vim, or it'll be a package conflict. Don't try and think for me what editor I want to use.

ahoka 1y ago
"I actually prefer the RHEL policy of leaving packages the way upstream packaged them" Are you kidding now? Red Hat was always notorious of patching their packages heavily, just look download an SRPM and have a look.
steeleduncan 1y ago
> I actually prefer the RHEL policy of leaving packages the way upstream packaged them I don't think RHEL is the right choice if this is your criteria. Arch is probably what you are looking for
mrweasel 1y ago
I don't think that's true for Red Hat, but it is true for Slackware. If you want packages that works just like the upstream documentation, run Slackware. Debian does add some really nice features in many of their packages, like a easy way to configure multiple uWSGI application using a file per application in a .d directory. It's a feature of uWSGI, but Debian has just package it up really nicely.
cess11 1y ago
Pretty much everyone has had nano as default for ages, at least that's how it seems to me from having had to figure out which package has script support and installing vim myself after OS install for a long time. And RedHat does a lot of fiddling in their distributions, you probably want something like Arch, which is more hands-off in that regard. Personally, I prefer Debian, it's the granite rock of Linux distributions.
yxhuvud 1y ago
> I actually prefer the RHEL policy of leaving packages the way upstream packaged them Unless something has changed in the last 10 years that has passed since I last used anything RHEL-based, there are definitely no such policy.

ahoka 1y ago

"I actually prefer the RHEL policy of leaving packages the way upstream packaged them" Are you kidding now? Red Hat was always notorious of patching their packages heavily, just look download an SRPM and have a look.

steeleduncan 1y ago

> I actually prefer the RHEL policy of leaving packages the way upstream packaged them I don't think RHEL is the right choice if this is your criteria. Arch is probably what you are looking for

mrweasel 1y ago

I don't think that's true for Red Hat, but it is true for Slackware. If you want packages that works just like the upstream documentation, run Slackware. Debian does add some really nice features in many of their packages, like a easy way to configure multiple uWSGI application using a file per application in a .d directory. It's a feature of uWSGI, but Debian has just package it up really nicely.

cess11 1y ago

Pretty much everyone has had nano as default for ages, at least that's how it seems to me from having had to figure out which package has script support and installing vim myself after OS install for a long time. And RedHat does a lot of fiddling in their distributions, you probably want something like Arch, which is more hands-off in that regard. Personally, I prefer Debian, it's the granite rock of Linux distributions.

yxhuvud 1y ago

> I actually prefer the RHEL policy of leaving packages the way upstream packaged them Unless something has changed in the last 10 years that has passed since I last used anything RHEL-based, there are definitely no such policy.