On 11/21/20 1:38 PM, L A Walsh wrote:
On 2020/11/17 05:18, Ludwig Nussel wrote:
Quite some packages carry around sections like this: #UsrMerge mkdir $RPM_BUILD_ROOT/sbin ln -s %_sbindir/foo $RPM_BUILD_ROOT/sbin/foo #EndUsrMerge That was added years ago as preparation of replacing /bin, /sbin, /lib and /lib64 with a symlink and merging the content into their counterparts in /usr. I'm not sure how that was supposed to work in practice though.
For many who had a separate physical disk for '/' and '/usr', and booted from the physical disk, it didn't work very well, but that was dealt with by just calling the old config, "not supported", so any problems caused by situations like that could be tossed out with "unsupported config".
It's happening again -- with various dirs moving off root and off /usr and under /usr/share (which got so big in my /usr, that I had to split it to /home/share and mount that on /usr/share).
Again, some similar potential problem points in that just like a separate /usr can't be mounted until root is available, a separate /usr/share can't be mounted until /usr is mounted. That always meant that tricks like putting 'mount' and/or its libs on /usr, and putting a symlink from /bin/mount -> /usr/bin/mount result in an unbootable system.
It seems there's also another move to put /etc/ => /usr/share/etc ? or was that tabled? There was a reason why file locations were specified in the LSB. Violating that will tend to make suse less compatible with other distro's which seems like useless churn, especially given that most authors will still put config files in /etc/. That makes a larger burden for suse to convert all [progs desired to run 'natively'] programs to the new format.
There are equally reasons for splitting up /etc which were mentioned in the thread, and seemed to be significant enough for people to be willing to invest in making the change.
That will make force app-writers to create a special version for suse -- something certainly likely to reduce the number of apps that easily work if you move them from many linux's to suse. in
Not really, in most plain cases packagers will make it work, for 3rd party apps if an app is expecting to use /etc it will still just work unless you are using a system with transactional updates configured.
It's sorta why perl became less popular over time. Different versions of perl became more incompatible w/each other -- especially as you go up the version chain. So more people come to the point of realizing that adopting or upgrading to the latest perl risks more incompatibility with previous versions.
So adoption of new perls has declined for the past 10 years or so. In the same way, someone wanting to distribute on linux, will lean toward those distros that provide the most inter-compatibility.
I'd disagree here atleast about the perl part. I can't remember the last time I did something and thought perl was the best language for the job. There are just better languages around now.
Are other Distros moving the /etc contents to the suse location?
Many are doing the split, but the location is pretty inconsistent so far, fedora / Red Hat were looking at /usr/lib for some reason. But the hard bit is teaching stuff to read from multiple locations i'm sure most distro's will settle on a standard at somepoint and then everyone migrating from whatever they pick now shouldn't be too bad. But splitting system and user config is a pretty different topic to moving files into /usr -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B