rawhide report: 20101019 changes

[seth vidal]

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