wishlist for TCL16

[GNUser]

Hi curaga. If possible, here are 3 features I think would be nice to have in TCL16:

* remove the useless /linuxrc symlink
* implement /usr merge
* turn on support for wifi usb adapters with rt53XX and rt55XX chipsets, which have been working great with the in-kernel rt2800usb driver for years

For third item, the kernel config options are CONFIG_RT2800USB_RT53XX and CONFIG_RT2800USB_RT55XX

[curaga]

I don't really deal with the first two much anymore, that'd be Juanito's alley. For wifi modules, are they still marked experimental? Generally we follow that mark.

[Juanito]

I’d prefer to continue using /usr for everything in the base and /usr/local for extensions.

[GNUser]

Hi curaga. I'm not sure if still marked "experimental" today. But I and others have tested these chipsets and they among the few that are stable enough on linux to recommend without reservations. The driver is already provided by wireless-KERNEL.tcz. Only users trying to use these chipsets would be affected if these config options were enabled.

Hi Juanito. Absolutely. That's not what /usr merge is about. The merge is about:

* eliminating /bin (which becomes a symlink to /usr/bin)
* eliminating /lib (which becomes a symlink to /usr/lib)
* eliminating /sbin (which becomes a symlink to /usr/sbin)

/usr/local and everything under it would be unaffected.

/usr merge simplifies the file system, leads to fewer broken absolute paths (for example, an application can look for either /bin/foo or /usr/bin/foo and both would work) and would increase compatibility between applications and TCL in the long run.

All that being said, TCL is already the best distro as-is. This would be a minor upgrade.

[GNUser]

Juanito, if /usr merge feels like too radical a change, then please disregard. One of TCL's strengths is that it is conservative and avoids big changes.

[curaga]

Okay, if you've tested those drivers, they can be enabled.

[GNUser]

Okay, if you've tested those drivers...

I have tested them and they work great.

...they can be enabled.

Many thanks! It will remove a long-standing rock in my shoe (recompiling this kernel module with each TCL release).

[gadget42]

with respect to the /usr merge i have reviewed the following:

https://forum.tinycorelinux.net/index.php/topic,26879.0.html
https://wiki.debian.org/UsrMerge
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#a-merged-usr-is-now-required
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://fedoraproject.org/wiki/Features/UsrMove

Understanding the bin, sbin, usr/bin , usr/sbin split - Rob Landley, 2010
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

and i also support Bruno's wishlist (as long as Juanito approves, naturally)

[GNUser]

    [Edit]: Continued from here https://forum.tinycorelinux.net/index.php/topic,27363.msg176504.html#msg176504  Rich

Hi Rich. What curaga was saying is that he doesn't want to move anything out of /usr/sbin into /usr/bin. I agree with him. That's called sbin merge and is not what polikuo and I are proposing.

usr merge is about doing away with the pointless splitting of some things into /usr/bin and other things into /bin, for example. This serves no purpose other than to break things (e.g., an application looks for /usr/bin/foo but cannot find it because on that distro it happens to be /bin/foo). usr merge forever fixes this kind of breakage while also simplifying the file system. It's win-win.

[GNUser]

Hi Rich. Please feel free to move these posts from this thread to the "wishlist for TCL16" thread here:
https://forum.tinycorelinux.net/index.php/topic,27276.0.html

After all, /usr merge has nothing to do with provides.sh (other than both being on TCL16 wishlist)

[Rich]

Hi GNUser

What curaga was saying is that he doesn't want to move anything out of /usr/sbin into /usr/bin. ...

Sorry, I missed that part.

[Rich]

Hi GNUser
I just got this interesting error message while loading an extension on TC15 x86_64:

Code: [Select]

ldconfig: invalid option -- 'q'
Try `ldconfig --help' or `ldconfig --usage' for more information.Turns out it was ldconfig from glibc_apps.tcz which doesn't support the quiet flag.
So I checked TC10 x86, and it defaults to the base ldconfig with glibc_apps.tcz installed.

Now here's the interesting part.
I grepped for ldconfig in glibc_apps.tcz.list for TC10-TC15 both 32 and 64 bit:

Code: [Select]

10.x x86  /sbin/ldconfig
11.x x86  /sbin/ldconfig
12.x x86  /sbin/ldconfig
13.x x86  /usr/sbin/ldconfig
14.x x86  /usr/sbin/ldconfig
15.x x86  /usr/sbin/ldconfig
10.x x86_64  /sbin/ldconfig
11.x x86_64  /sbin/ldconfig
12.x x86_64  /sbin/ldconfig
13.x x86_64  /usr/sbin/ldconfig
14.x x86_64  /usr/sbin/ldconfig
15.x x86_64  /usr/sbin/ldconfig
TC10 defaulted to the base ldconfig because:

Code: [Select]

tc@E310:~$ grep "Overwrite" /usr/bin/tce-load
FORCE="n"  # Overwrite system files default to no. Use -f to force overwrite.
tc@E310:~$That's probably why it got moved to /usr/sbin/ldconfig in TC13.

Base install also includes  /usr/bin/ldd.  glibc_apps.tcz provides:

Code: [Select]

10.x x86  /usr/bin/ldd
11.x x86  /usr/bin/ldd
12.x x86  /usr/bin/ldd
13.x x86  /usr/bin/ldd
14.x x86  /usr/bin/ldd
15.x x86  /usr/bin/ldd
10.x x86_64 
11.x x86_64  /usr/bin/ldd
12.x x86_64  /usr/bin/ldd
13.x x86_64  /usr/bin/ldd
14.x x86_64  /usr/bin/ldd
15.x x86_64  /usr/bin/lddI wonder why it's missing in the 10.x x86_64 version?

Anyway, I thought I'd point those two out since they conflict with the
merge and you'll want a fix that doesn't cause unexpected behavior.

[GNUser]

Hi Rich. Interesting find. Thanks for sharing.

Before usr merge gets too much of our mindshare, it would be nice if Juanito would weigh in on whether it will happen for TCL16 (or ever). If not, we don't have to worry about wrinkles. If so, I'll be happy to roll up my sleeves and help sort out this issue and any others that may arise.

[Juanito]

I’m not that keen as the current setup doesn’t cause me any problems, but that makes Curaga, Rich and yourself that are for it/not against it, so we could try it.

[GNUser]

Hi Juanito. I'm glad you are willing to try it. I think you'll like it. If not, we can just go back to the traditional filesystem layout and put the usr merge idea to rest.