[olpc-software] Package manager stuff

Mike Hearn mike at plan99.net
Wed Mar 15 22:31:25 UTC 2006


On Wed, 2006-03-15 at 17:13 -0500, David Zeuthen wrote:
> I wonder... what's wrong with a cheap-skate solution including a daemon
> that just create / destroy symlinks in /usr when it sees files come and
> go in /applications and /media/<mountpoint>/? 

Well, it's cheap and nasty :) 

It could be done but it'd complicate the daemon a fair bit, because it
would have to duplicate all the stacking logic that unionfs already
takes care of. And it'd be nice to make unionfs work properly with file
notifications anyway - I don't know how much code the layer propogation
stuff would be, but I'll try to find out. Possibly if we blow off the
scary shared subtrees stuff it wouldn't be much harder than doing
symlink farming.

On the other hand, it means avoiding the kernel (yay!) and is presumably
easier to understand for developers. And if unionfs hacking turns out to
be scary it's definitely an idea worth trying.

I'd like to carry on investigating the unionfs approach first though,
even though it's currently independent of the mainline kernel.

> Perhaps this is what you meant with a FUSE solution in an earlier mail?

There are two union fs implementations for Linux that I'm aware of, the
main one which is an in kernel solution and has pretty good performance,
and a FUSE one which I have never tried and don't know much about.

> Question: what would the cost of having /usr with symlinks on tmpfs be?
> Both space-wise (how much RAM would it take) and CPU-cycle wise (how
> much time would it take to populate /usr)? IIRC tmpfs is rather smart
> these days (don't use a full 4kb inode for every file); this happened
> after certain distributions (including Fedora) started using it
> for /dev.

I have no idea, that's a question for Alan, but there's no need to
have /usr be entirely made of symlinks. Splitting the system stuff
into /system was done because unionfs requires an empty directory to be
mounted onto so it can compose other directories into it. It's not a
fundamental part of the design.

thanks -mike




More information about the olpc-software mailing list