> >Well, there were a couple of reasons why I wanted to go with these > >numbers: > > > >(1) Accomodate the crazy Everything install people now. > > That is a good point. Better to handle everything in Fedora rather than only > a subset (even though the subset is what the majority of users will ever have > installed). I'm really only a little concerned about the Everything case. Perhaps that should not have been my lead-off point. > >(2) Provide enough room to store packages when doing yum upgrade or > >preupgrade. > > Also a good point. This one I am much more concerned about, and I think that someone doing even a half-Everything install is likely to bump into the size limit of / on preupgrade if we set it too small. > >(3) Make it big enough so we don't have to worry about bumping the size > >up every release as the distribution gets bigger. > > We can say that now, but we'll still have to keep an eye on this number just > like we have to keep an eye on the size for /boot. Yep, agreed. Guess what we'll periodically forget to do. > For the standard hard disk size we see now, 50GB is nothing. Netbooks present > a different use case. Are those users interested in a separate /home by > default? Should we care? They may be interested in a separate /home, but as I told Hans elsewhere, I don't think we're going to be able to reasonably come up with a split for them. It's just too tight. I am willing to punt on this, unless someone is really clever. > I'll agree that 50GB is fine for the normal sized hard disk use case, but > maybe we should break this in to a few different cases: > > - The regular hard disk, which for the sake of argument is 250GB > or larger by default. > - The netbook user or someone with 8GB to 64GB of storage available. > - The live CD user, where we already know what will go to / before > we get to partitioning setup. > > At least the first and last ones there seem like ones worth tackling. The > netbook use case may be harder to define. Netbooks now have hard disks as > well as SSD. We have a netbook here with a 250GB hard disk in it and my > Thinkpad from RH has a 64GB SSD in it. Go figure. I'd agree with this breakdown. I just think I've got them pretty well covered. > >>1) For live installs, we know the size of what's going to /, so we could use > >>that as the basis for sizing /, then make /boot, swap, and /home. > > > >True, we could be smarter here. That would have to involve setting this > >default partition in the backend and might be a little difficult. > >However, it could be a decent refinement. > > Given how hard the live install concept is sold, I think it would be worth our > time to do something for this use case. Given how easy it is for the user to install extra stuff, do the two use cases really end up being all that different in their space requirements? I suppose server installs are less likely to be done via livecd and they have different space requirements than desktop installs. But, we're not making and server vs. desktop decisions in anaconda at all right now. > >>2) x86 may have a smaller / requirement than x86_64, should that be > >>considered? > > > >Eh, I don't know that it's too important. But it would be easy enough > >to take into account with the Platform module. > > On second thought, this is probably a waste of time. I don't know what the > size differences are between an everything x86 and everything x86_64 install. > Maybe it's not that great. I believe the CD set for x86-64 frequently ends up being one CD larger than the i386 set. So at maximum, we can say that today the x86-64 install is one CD's worth of exploded packages larger. That's probably not more than 1 GB of extra stuff, so it doesn't seem like worrying about too much. Was that enough handwaving? > >Only if we can call it /Users. > > Not "/Documents and Settings"? I think that's more of a subdirectory: /Users/Chris Lumens/Documents and Settings - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
