re: libquota proposal

[matthew green <mrg%eterna.com.au@localhost>]

> On Sat, Mar 19, 2011 at 09:40:18AM +1100, matthew green wrote:
> > 
> > this seems reasonable to me.  why don't you stick it in libutil?
> > 
> > > As this is needed to get netatalk to build again on HEAD, I'd like
> > > to commit this in the next few days.
> > 
> > this is what i'm talking about about using a different name for
> > the new syscall that takes totally different arguments.
> > 
> > is there absolutely no chance for old code to work with the new
> > kernel?
> 
> It won't work: old code looks at the filesystem type, and fstab
> entries for userquota/groupquota options. So, even if we made it
> compile again, it would only look for quota on ffs with quota1;
> it would miss ffs with quota2, mfs, or anything else that will
> have quota in the future.

i understand this -- you need to use the new API to access
the new functionality.

my question was more: what's *broken* to let old code build
and run against the old API?  clearly, apps need to have
new patches to talk to the new API, but is there a reason to
make it *impossible* to use the old API?  i am not going to
claim they exist, but what if someone is running an older
netatalk for some reason, and they'd rather rebuild than
port your patches.

breaking source compat like this is just nasty.


.mrg.