The issue is the problematic usage of the word "legacy" by the author. It is disparaging, almost like trolling.
Being "legacy" or not has nothing to do with the number of users. There are many cutting-edge distributions that (gasp!) do not even use systemd. Would you call those, "legacy"?
Look at the definition of the word, in the context of computing, according to the Oxford dictionary: "denoting or relating to software or hardware that has been superseded but is difficult to replace because of its wide use".
If anything, the most "legacy" distributions should be redhat and debian, and their respective derivatives.
No he is correct, the usage is not problematic or disparaging. It fits your definition exactly. The only practical reason to still have the /usr split is to support an obsolete configuration on very small hard drives, which is no longer actually in use by any of the modern distributions. And the real reason any modern distribution still has it is because it's hard to change it, not because they actually want to. So that very much fits the definition that you just posted.
PREFIX support is different for every second buildsystem upstream offers. You'd need to patch that, its a ton of work. Manpower that needs to be invested without having a commercially visible return - thats why commercial distros rarely do it and possibly never will if upstream does not start doing it out-of-the-box.
Rejecting the /usr split is worth it just for the purpose of not having to clean up after Lennarts ideas. He isn't the guy who carries the fallout, even when he is the one causing it.
I'm sorry I don't understand what you're talking about at all. PREFIX support makes it even easier to support the usr merge. You don't need to patch it if it's already there.
>Rejecting the /usr split is worth it just for the purpose of not having to clean up after Lennarts ideas.
This makes zero sense, the main reason to do this is for compatibility with container tools and other things that benefit from having a simplified mount structure. It was not an idea that came from systemd and it also has nothing to do with "cleaning up after" anyone's ideas.
> I'm sorry I don't understand what you're talking about at all.
Have you ever written or maintained recipes for building software? PREFIX= support exists, but its not consistent and many packages need individual workarounds. Adjusting it is quite some work.
Which distro do you use? Made by whom? Be grateful that these guys do this work for you.
Yes I have, and build systems without working PREFIX support are going to be really broken and need workarounds in a lot of scenarios, not just this one. It's always going to be quite some work. I actually recoil in pain now whenever I see someone ship something with a giant makefile or a big folder full of system-specific shell scripts.
For obscure packages with a weird build system they often aren't doing the work for me, specifically because those build systems are hard to manage and nobody wants to deal with them. If you want distros to not package your software that's a great way to do it. If you want to discourage contributors from sending you patches because they can't figure out your build system then that's also a great way to do it.
If you're a big popular package like Chromium or Firefox then you can get away with having a weird build system but even then packagers don't want to deal with it past a certain point, hence browsers packaged in Snap and Flatpak...
>but a neat, simple and portable makefile is a beautiful sight to behold and a pleasure to run.
As someone who has had to hack those makefiles a lot, I can't really agree. There's no such thing as a "simple and portable makefile". The real way to generate "portable makefiles" is to use autotools. Every handwritten "portable makefile" I've seen actually has a ton of system-specific and compiler-specific rules. And when porting from Linux you're lucky if some package shipping a handwritten makefile doesn't have an undocumented dependency on GNU make.
Even something simple like PREFIX support has to be manually implemented and tested if you write your own makefile, and often the upstream project doesn't bother testing it and wants the distro to do it. If you want distros to package your stuff without any troubles and without making them a guinea pig for some weird ad-hoc build system then it would be easiest to just use one of the standard buildsystems, those are mostly just cmake, meson, autotools. A small cmake or meson script is significantly shorter than a makefile and is a lot more portable.
