On Tue, 2010-10-19 at 16:08 +0100, Matthew Garrett wrote: > On Tue, Oct 19, 2010 at 11:03:50AM -0400, seth vidal wrote: > > On Tue, 2010-10-19 at 15:56 +0100, Matthew Garrett wrote: > > > > > > /usr is frequently given different mount options (like noatime, for > > > > example) or mounted readonly to prevent unnecessary writes to the > > > > system. > > > > > > That doesn't require it to be a separate partition. > > > > Mounting the location meaningfully as a readonly does. If you're doing > > it for security reasons. > > It doesn't. You can make it a read-only bind mount. If the files are still read-write at another location then something iterating over disks/locations can still find it. That's what I meant by meaningfully. > > I'm confused here - why is it we have to come up with a plausible > > reason? Why is the burden of proof on KEEPING /usr as a separatable > > partition? > > Because it takes more engineering effort to keep it as a separate > partition, as evidenced by the number of bugs that keep appearing that > are only triggered by this niche usecase. Hmm, So when this was broken a lot of bugs were triggered? Sure seems like if a lot of bugs are being triggered then it is NOT a niche usecase. You can't have it both ways. > > If I said tomorrow "yum will not support feature foo or bar" that have > > been in rpm and yum since the dawn of time I'd have to defend my > > rationale for that change. > > If yum removed features that provided functionality that could be > achieved via other means, and in return various other features worked > better, I'd be fine with that. It's not clear to me that other features work better in the case you're describing and it will mean retooling for what sounds like a good number of users. > > So it seems like you need to explain why you think /usr should NOT be on > > a separate partition. > > Because it adds additional complexity for no obvious gain. that's not plausible enough, imo. There is clear gain to enough users to file a 'number of bugs'. -sv -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
