> On Feb 4, 2021, at 8:39 AM, Lamar Owen <lowen@xxxxxxxx> wrote:
>>
>> I posted a pretty complete rundown on the scientific linux users mailing
>> list, so I won't recap it all here.
>
> Link?
>
>> the transition was not any more difficult, really, than moving from
>> CentOS 7 to CentOS 8.
>
> That’s not my experience.
>
> I keep several of my packages running on CentOS and Debian (and more) and
> I keep running into several common problems:
>
> 1. The package names are often different, and not always differing by an
> obvious translation rule. For instance, it’s “openldap-devel” on CentOS
> but “libldap2-dev” on Debian, where the normal rule would make it
> “libopenldap-dev”. Why the difference? Dunno, but I have to track such
> things down when setting up scripts that do cross-distro builds. If I
> automate that translation, now I’m setting myself up for a future breakage
> when the package names change again. (libldap3-dev?)
>
> 2. Some packages simply won’t be available. Most often this happens in
> the Debian → CentOS direction, but I’ve run into cases going the other
> way. Just for one, I currently have to install NPM from source on Debian
> because the platform version won’t work properly with the platform version
> of Node, last time I tested it. Why? Same answer as above.
>
> 3. Debian adopted systemd, but it didn’t adopt the rest of the Red Hat
> userland tooling. For instance, it’s firewalld on CentOS, UFW on Ubuntu,
> and raw kernel firewall manipulation on Debian unless you install one of
> those two. And then, which?
>
> 4. Network configuration is almost entirely different unless you turn off
> all the automation on all platforms, in which case you might as well
> switch to macOS or FreeBSD for all the good your muscle memory and
> training will do you.
>
> I’m not saying “don’t do it,” but to say it’s as smooth as from CentOS 7
> to 8? Hard sell.
>
> I’ll give you one mulligan: the changes to the security rules in CentOS 8
> caused a huge upheaval for one of my applications, since it basically
> stopped it from running, being naughty in Red Hat’s omnisciently
> beneficent eyes. We spent about a year fixing breakages due to 25 years
> of built-up assumptions about what was correct and sensible, which don’t
> affect us on other Linuxes because they didn’t implement the same SELinux
> rules.
>
> The details aren’t super-important, because the real take-away is this:
> it’s always *something.*
>
> (For those that must know, the biggie was that our systemd-based service
> used to run from /home/$APPNAME but that’s a no-no on C8 now. Moving it
> all under /opt/$APPNAME and rearranging it all according to LFS rules,
> then finding and fixing all the places we depended on such paths was
> *painful*.)
Thanks for the big fat warning, now I know exactly what I'll have to do
sooner or later :)
Part of the problem is this: there was FHS 2.x and all was good. Then some
devs started with new tools like systemd and didn't care about FHS and
reinvented some new wheels. Later, after the new facts were established,
the FHS was adjusted to the new taste of things and people like you and me
were left with the mess :)
Simon
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
