On Tue, 2011-10-18 at 12:07 -0400, Jonathan Kamens wrote: > On 10/18/2011 11:58 AM, Chris Lumens wrote: > > The amount of work you're describing here is huge, and the number of > > people who would benefit from such a setup is very small. I'd guess > > that for whatever scenario you can imagine, another scenario can be > > imagined that would not be able to be handled. > I disagree with just about everything you've said above. > > RPM has a few, not really all that many, safeguards for not > overwriting config files, files of different types, etc. The change > I'm proposing is small and relatively contained -- add a mode to RPM > where all of those safeguards are turned off. Allow RPM and anaconda > to create everything that want to create as if it's a brand-new > installation, and any time anything is in the way (and there really > are not that many such cases, so it's not "huge" at all), just blow it > away. > > I don't want to start haggling over details of example after example, > > but just to give you one example to make this a more concrete > > discussion. Let's say you do an x86-64 installation. You then later go > > and do an i386 installation reusing the / from before. You now have two > > sets of the libraries laying around, for different architectures. What > > happens? > The x86_64 libraries are irrelevant to RPM and Anaconda and ignored by > them during the installation. Similarly, they are ignored after the > installation, because nothing in the config files and such that were > installed references them. They're cruft, just like all kinds of other > cruft that accumulates over time on a disk. In the scenario you > described, the person who chose to overwrite rather than > reformatting / chose to allow that cruft to remain, and it's his/her > choice to make. > > Not to mention that making design decisions based on rare corner cases > like this one is not a good way to design software. > > Clearly, using an already-formatted / is not a rare corner case. > Several people have spoken up here about what they use it for and why, > and their uses cases are reasonable and necessary. > > In both of these scenarios, it's not that there's some config file > > confusing anaconda. It's files owned by RPMs that would not be > > overwritten by installing something else, and those files will cause > > problems. How do you even determine what's "unexpected" or "of the > > wrong type"? > Anything. Anything at all. You're doing a fresh install. So install > everything, and if anything gets in the way, blow it away. It's much There's more going on here than what "gets in the way". Not all of these cases announce themselves so clearly. Applications can be coded to look for things in a variety of places. Do you expect anaconda to keep a list of every such location that every application might look in so that we can ensure that no stray files are present that will cause problems? Not very reasonable at all. > simpler than you're making it out to be. No, it's much more complicated than you're making it out to be. The time it takes to figure out what is happening when these types of issues arise is a) too great given the odd, apparently random nature of the misbehavior and b) a total waste of developers' valuable resources. There is nothing weird or tricky about creating a separate /home filesystem. You can use fs profiles (man mke2fs.conf, see ks --fsprofile option) with kickstart to get the options you want applied when your rootfs is created. There is a way out of this that does not involve installing to systems in an unknown state. Learn to use it. Dave > > jik > -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
