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