Thread: iLiad Ruby 1.8.5 for iLiad
View Single Post
Old 01-12-2009, 09:51 AM   #13
-Thomas-
Addict
-Thomas- once ate a cherry pie in a record 7 seconds.-Thomas- once ate a cherry pie in a record 7 seconds.-Thomas- once ate a cherry pie in a record 7 seconds.-Thomas- once ate a cherry pie in a record 7 seconds.-Thomas- once ate a cherry pie in a record 7 seconds.-Thomas- once ate a cherry pie in a record 7 seconds.-Thomas- once ate a cherry pie in a record 7 seconds.-Thomas- once ate a cherry pie in a record 7 seconds.-Thomas- once ate a cherry pie in a record 7 seconds.-Thomas- once ate a cherry pie in a record 7 seconds.-Thomas- once ate a cherry pie in a record 7 seconds.
 
-Thomas-'s Avatar
 
Posts: 325
Karma: 1725
Join Date: Dec 2007
Location: Münster, Germany
Device: iRex iLiad v2
Quote:
Originally Posted by hansel View Post
But it's still unaccaptable if one preinstall script deletes the symlinks created by another preinstall script. The symlinks should only be created if not present. Example: if I release a package to install Lua, and install it from /mnt/free, it would remove the symlink to the cf card, and break the Ruby package and all programs that use Ruby.
That's right. But for me it's the other way round: Let's assume I would install Lua to CF and Ruby to the internal memory, as it's of greater value for me. Then how would you compile both programs so that both of us can use it if not with --prefix=/usr/local? By choosing somethink like --prefix=/mnt/free/local you force users to use the internal memory, which could be something they don't want. In the end it's a trade-off between flexibility and package consistency, where I would prefer the flexible way. If we want to let the user choose which storage medium they want to use there is no way around symlinking IMO.

Of course symlinking breaks the ipkg mechanism in a serious way, but I think it's the most consumer-friendly way, if you stick with the assumptions I made in my last post.

Quote:
What can we do about this?
The only real solution would be if we had bigger storage in /, but that's not an option at the moment.

We should also think about the "legacy" software that is already out there, they were all compiled to use /usr/local. This software should still be useful in the future. Well, this should not be an argument for symlinking /usr/local somewhere, but /usr/local should be involved in some way.

Isn't there a file system that can mount several partitions transparently to the same directory? I think the Knoppix Live DVD is using something like this to assure "write access" to their read-only CD image. If this would be possible we could just mount all /media/*/_local to /usr/local and would be done.

Quote:
I'm currently playing with Lua scripts that I want to run from start.sh... Maybe I shoul refrain from installing in /usr/local (linked to /mnt/free/local)? and install directly in /mnt/free?
I'd better go for /usr/ if you want to run it from start.sh and it's an important script. Maybe I'm a bit conservative when it comes to changing the start.sh

Quote:
Another reason te install in internal flash is the problems involving wifi when accesssing cf. I can solve that by buying a mmc card... B.t.w. Is there still a problem with Wifi and CF in 2.12? I never testetd this myself...
It's still there (it's merely a hardware design flaw), but it's easy to work around. My Feedbooks plugin for example first downloads to /tmp and moves files to CF afterwards to avoid simultaneous Wifi and CF access.
-Thomas- is offline   Reply With Quote