Re: install non-core udebs to /usr/local
Joey Hess wrote:
>
> Glenn McGrath wrote:
> > Well, if we need more than 4MB of space in /usr then it will mean that
> > we can only install to machines with more than 8MB, which effictively
> > means you need 16MB to install debian.
>
> BTW, where is the 1/2 of ram limitation documented? I read the code but
> didn't see what sets that.
>
Actually looks like i was wrong... i did a search a found a snippit of
code that refered to a default 1/2 physical memory limit, but looks like
the patch wasnt applied.
I just made a ramdisk and did dd if=/dev/zero of=/mnt/space, i got the
file to about 100MB but my system started churning swap space, so i did
a ^C and have tryied to remove the file i created, no luck yet, it may
require a reboot.
So maybe 1/2 physical ram might be a *rough* limit that we can go by.
> Anyway, if we needed 6 mb of space for /usr, a 12 mb machine would work
> too, not just 16. But I take your point.
>
I guess i exagerated a bit, becasue in practive ram size usually goes up
in jumps of 2, its not that common (in my experience) for machine to
have >8 and <16
> > In my eyes this would be unacceptable, im all for useing ramfs to make
> > the most of machines that do have a lot of RAM but we have to have a
> > backup plan for those who dont.
> >
> > If we can get a loopfs working we might even be able to install to
> > machines with 4MB
>
> I see nothing wrong with leaving loopfs support as an option to be
> written later if we find it is needed. So long as all it requires is a
> seperated out /usr.
>
> Here's a problem we have to work out before we can make /usr be used for
> non-core d-i udebs though: What is a core d-i udeb?
>
> On a system being installed via the net, the wget-retreiver is core. On
> a system being installed from cd, where the user wants to use
> wget-retreiver to download something else after some udebs are installed
> from cd, wget-retreiver is not core.
>
> So aside from some really basic stuff like the libc and a minimal
> busybox and main-menu and anna, whether something is a core component
> that needs to go in / as opposed to /usr depends on how it is going to
> be used.
>
> Ideas?
>
Well core components should be components that are essential, i guess
its essential that there be one working retriever, but it doesnt matter
what that retriever is (net, floppy, hdd, cd) it can be used to get a
preffered retriever.
I guess that sort of description doesnt make it easy to say absolutely
where individual retrievers should go. Maybe we could generalise and say
the primary retriever is core and belongs in the root filesystem and
further retrievers are non-core and belong in /usr... maybe...
Glenn
Reply to: