[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [olpc-software] No package manager?



On Tue, 2006-03-14 at 20:12 -0500, Christopher Blizzard wrote:
> Alan Cox wrote:
> > But there is a reason you want the package concept visible to users,
> > a really important one. Most bandwidth is local in this mode so you want users
> > to have a visible concept of giving each other programs. "I'll get the maths
> > tool you get the book we need to read and we'll swap over later this evening"
> > is a concept that requires users awareness of packages, even if not of
> > "installation"
> 
> Yeah, I don't think anyone is suggesting that we hide the packages from 
> users, the question is how it's exposed to users.  Is the maths tool 
> you're talking about one package or one application backed up by three 
> different packages?  

My suspicion is that all applications may end up as at least two
packages: the code and the translations, at a minimum. Along with
whatever they depend on.

The extreme case is the one we took in familiar, where we *had* to fit a
usable environment into 16 meg of flash total: on that distro, we ended
up packaging just about each library, driver, and kernel module as an
independent package. ldd is your friend ;-)  Ergo my conversation with
you about a "repackaging tool", to aid this process and to allow
leverage standard packages as much as possible.

> And where are they installed on disk?  

Your desire for out of place installation resonates with me.  I'm not
convinced it really solves the problem in the abstract, though.

> And what 
> happens when you remove the maths package?  

> Are the dependent packages 
> removed as well if they aren't used?  

There has to be either an automatic or manual GC (manual in the sense
that when you run low on space, you hit "cleanup"), or it is likely you
end up with accretions of unused stuff with time.  Each has its
merits/demerits: automatic, it just works without any cognitive load;
manual, and you are more likely to have stuff around and have less to
fetch from somewhere.

One can also imagine date based schemes, where orphan packages get
cleaned up automatically if not referenced for some period of time, or
space based schemes, where you GC orphans to generate space needed for
new installations.


> How do you tell what an 
> application is instead of a library?  

Generally a good thing to tell the packaging system, in my view.

IIRC, we defined a way to identify end user applications in
familiar/ipkg, so that our package manager GUI didn't by default have to
show the tons of small packages no end user cared about that they
depended on. 

Mathew Allum almost certainly remembers exactly what we did (as he built
one of the GUI's we used, as I remember).


> What happens when a kid tries to 
> share that maths package - is the rpm or dpkg and all of its dependent 
> packages reassembled, moved over to the peer machine and then installed 
> over there as well?

Sure, though all you really have to do is copy the indicated files of
the packages; you don't have to actually have reassemble the package
itself.  Just use the inventory information to tell you what files need
to be moved.

There is one wrinkle that occurs to me: how to deal with configuration
files; sounds like saving the distribution conf files in a standard
fashion with their checksums will be needed.

I'll bring in my iPAQ and Nokia 770 for you to play with.
			Regards,
				- Jim
d




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]