wishlist for TCL16

[GNUser]

Hi Rich. If we go with usr merge, it would decrease the number of available places to put executables in base, somewhat simplifying this problem.

For base, the options would be /usr/bin or /usr/sbin. So ldd can stay where it is (at /usr/bin/ldd) and ldconfig would be moved from /sbin/ldconfig to /usr/sbin/ldconfig.

Is there a reason why glibc_apps.tcz uses /usr/bin, /usr/sbin, and /usr/lib rather than follow our convention for extensions and use /usr/local/bin, /usr/local/sbin, and /usr/local/lib? It was either an oversight or the intention was to overwrite the versions in the base system.

Since some users may be using the glibc_apps.tcz version of ldconfig, TCL scripts should either a) use only flags that work with both versions of ldconfig or b) if the two versions of ldconfig can coexist on same system, force the base system version by using full path.

[Paul_123]

Silly question, ldconfig is not part of core scripts.  If it’s not from glibc, where does it come from?

[GNUser]

Hi Paul_123. I assumed the ldconfig in base system was either part of BusyBox or a shell script by Robert, but I just checked and it seems to be neither. So I have no idea where it comes from. That's not a silly question.

Can one of the other developers shed light on where the ldconfig in base system comes from?

[Rich]

Hi Juanito

... but that makes Curaga, Rich and yourself that are for it/not against it, so we could try it.

I never said I was for it.

To be honest, I had concerns there might be conflicts, but I couldn't find any examples
at the time. Since I couldn't provide any examples, I didn't raise any objections.

I preferred:
/bin/  =  Base
/usr/bin/  =  Unique to distro (tce-load, tce-audit, etc) and basket case hard coded stuff.
/usr/local/bin/  =  Extensions

I like the separation and it works.

[GNUser]

I never said I was for it ... I had concerns there might be conflicts ... I like the separation and it works.

Hi Rich. Wish you guys had expressed your reservations sooner Knowing Juanito is not keen on it and Rich has concerns would have caused me to stop barking up this tree a long time ago.

To be honest, most of the path-related breakage I run into is because we keep extension stuff in /usr/local. I'm not suggesting we change this! The system makes sense, problems are uncommon, and workarounds are easy. Problems arising from some things being in /bin while others are in /usr/bin are rare in comparison, so it is certainly possible that implementing usr merge would cause more problems than it would fix.

I'll drop the topic, but am glad it was considered and discussed.

[Juanito]

Silly question, ldconfig is not part of core scripts.  If it’s not from glibc, where does it come from?

I believe Curaga provided it, maybe from uglibc?

[Juanito]

I preferred:
/bin/  =  Base
/usr/bin/  =  Unique to distro (tce-load, tce-audit, etc) and basket case hard coded stuff.
/usr/local/bin/  =  Extensions

I like the separation and it works.

That’s also my preference

[Juanito]

Is there a reason why glibc_apps.tcz uses /usr/bin, /usr/sbin, and /usr/lib rather than follow our convention for extensions and use /usr/local/bin, /usr/local/sbin, and /usr/local/lib? It was either an oversight or the intention was to overwrite the versions in the base system.

The reason is that glibc is compiled to /usr because it’s in the base and I was concerned that some of the scripts would point to the wrong place if I recompiled the parts not in the base to /usr/local

[GNUser]

I like the separation and it works.

That’s also my preference

Case closed, then. Thank you guys for considering it.

[Rich]

Hi GNUser

... Hi Rich. Wish you guys had expressed your reservations sooner ...

I didn't feel it was right to cry wolf before I'd seen one.

[Rich]

Hi Paul_123

Silly question, ldconfig is not part of core scripts.  If it’s not from glibc, where does it come from?

I did a search of the repositories and all I could find was this:
http://tinycorelinux.net/5.x/x86/release/src/ldconfig/

I also unpacked microcore.gz from TC2 and found this:

Code: [Select]

tc@E310:~/UsrMerge/tmp$ ls -l sbin/ldconfig
-rwxr-xr-x 1 root root 40476 Dec  7 15:41 sbin/ldconfig
tc@E310:~/UsrMerge/tmp$

[Paul_123]

Well piCore is using ldconfig from glibc in the base.  I’ll have to check/try that source

[Rich]

Hi Paul_123
I also found this:

Our kernel is vanilla, ie it supports firmware blobs. Only ldconfig is statically linked (and from uclibc), everything else is dynamic. ...

[CNK]

Also running "ldconfig -v" on TC15 x86_64 the terminal output starts with:

Code: [Select]

ldconfig: uClibc version


[Rich]

Hi Paul_123

... I did a search of the repositories and all I could find was this:
http://tinycorelinux.net/5.x/x86/release/src/ldconfig/ ...

I revised my search. I think this may be more useful:
http://tinycorelinux.net/4.x/x86/scm/src/gentoo-buildhost/distfiles/gcc-4.6.3-uclibc-patches-1.0.tar.bz2

http://tinycorelinux.net/5.x/x86/release/src/ldconfig/uclibc-ldconfig-glibc-compat.patch
http://tinycorelinux.net/5.x/x86/release/src/ldconfig/uClibc-a9bdc5d28e692c04f51bcea1bb8e87f9c72ad09f.tar.xz

http://tinycorelinux.net/8.x/x86/release/src/toolchain/uclibc_x86.config
http://tinycorelinux.net/8.x/x86/release/src/toolchain/uclibc-ldconfig-glibc-compat.patch
http://tinycorelinux.net/8.x/x86/release/src/toolchain/uClibc-0.9.33.2-ldconfig-x64-p-option.patch
http://tinycorelinux.net/8.x/x86/release/src/toolchain/uClibc-0.9.33.2.tar.xz
http://tinycorelinux.net/8.x/x86/release/src/toolchain/compile_uclibc
http://tinycorelinux.net/8.x/x86_64/release/src/toolchain/uClibc-0.9.33.2-ldconfig-x64-p-option.patch
http://tinycorelinux.net/8.x/x86_64/release/src/toolchain/uclibc_x86_64.config
http://tinycorelinux.net/8.x/x86_64/release/src/toolchain/uClibc-0.9.33.2.tar.xz
http://tinycorelinux.net/8.x/x86_64/release/src/toolchain/compile_uclibc

http://tinycorelinux.net/11.x/x86_64/release/src/toolchain/uClibc-ng-1.0.33.tar.xz
http://tinycorelinux.net/11.x/x86_64/release/src/toolchain/glibc-uclibc-compat-ld-cache.patch
http://tinycorelinux.net/11.x/x86_64/release/src/toolchain/uclibc-ldconfig-x64-p-option.patch
http://tinycorelinux.net/11.x/x86_64/release/src/toolchain/compile_uclibc

http://tinycorelinux.net/12.x/x86/release/src/toolchain/glibc-uclibc-compat-ld-cache.patch
http://tinycorelinux.net/12.x/x86_64/release/src/toolchain/glibc-uclibc-compat-ld-cache.patch

http://tinycorelinux.net/13.x/x86/release/src/toolchain/glibc-uclibc-compat-ld-cache.patch
http://tinycorelinux.net/13.x/x86_64/release/src/toolchain/glibc-uclibc-compat-ld-cache.patch

http://tinycorelinux.net/14.x/x86/release/src/toolchain/glibc-uclibc-compat-ld-cache.patch
http://tinycorelinux.net/14.x/x86_64/release/src/toolchain/glibc-uclibc-compat-ld-cache.patch

http://tinycorelinux.net/15.x/x86_64/release/src/toolchain/glibc-2.38-uclibc-compat-ld-cache.patch

I unpacked core.gz for a bunch of TC x86 versions to see when ldconfig changed size:

Code: [Select]

CorePlus 4.7.7    40476
CorePlus 5.4      40476
CorePlus 6.4.1    35104
CorePlus 7.2      35104
CorePlus 8.2.1    37116
CorePlus 10.1     37116
CorePlus 15.0     37116The 35104 size matches the copy in http://tinycorelinux.net/5.x/x86/release/src/ldconfig/
It appears ldconfig is unchanged starting with TC8 through TC15.