2011/6/26 Kent Fredric <kentfred...@gmail.com>: > 2011/6/26 Jesús J. Guerrero Botella <jesus.guerrero.bote...@gmail.com>: >> I am really amazed that someone didn't want to use links (a solution >> with next to zero work involved) because they are not available in >> fat32 (as if fat32 was relevant at all for us) but then people is >> suggesting that we should put everything into a flat folder and use >> tags. > > Well, the difference being "Symlinks are only really surplus utilities > that make it easier for users" and "Some degree of backcompat" instead > of "Core Functionality that will be required to make the code work". > > In theory, if you have the "most recent" versions of your package > manager, after this change takes place, you will not need any symlinks > at all, and functionality should still be retained if they were blown > out completely.
The real question is why something that has been into POSIX since ever can't be used for something that has also always been fs-based since it was born (that's "portage"). I an not saying that this other system doesn't have it's advantages. I am just saying that if I wanted a db-like-but-not-db-based system I'd probably reinvent any .deb or .rpm based distro, rather than retouch something based (even marginally) on BSD ports. That still doesn't answer my question anyway: both features (symlinks and +65k files on a single dir) are incompatible with fat32. And someone said fat32 compatibility is a feature we want (still can't guess why, but well, be consequent...). Obviously, we want fat32 compatibility when it comes to arguing against symlinks, which have always been with us by the way, but that's not important when we talk about other things that are not compatible with fat32. Links seem to look not so elegant today, but we use them everyday for eselect, /etc and even in the handbook. but Oh!, They are not that good for portage. -- Jesús Guerrero Botella
