>
>[ On Wednesday, October 17, 2001 at 03:29:54 (-0400), James Chacon wrote: ]
>> Subject: Re: stdio FILE extension
>>
>> "to go from 1.5 -> 1.6 requires you to recompile everything in pkgsrc and
>> you either have to learn the build system so you can prebuild before
>> converting or lose all of /usr/pkg after upgrading before you rebuild..."
>> 
>> just does them a disservice.
>
>Now you're just being silly.
>
>What that group of users would really do is just re-install all the
>pre-compiled binaries supplied on the 1.6 CD they upgrade from.

That's rich..."To upgrade, wipe your disks and install everything fresh
from the cd..Oh by the way some of your favorite utils might not be the
same version anymore..Deal"

What you may personally do as part of system upgrades is one persons concern,
yours...There are many different ways to support upgrading systems and
tunneling it down to just the method you happen to use/like is pretty 
ridiculous. I know plenty of people who upgrade new OS versions without
upgrading their apps. You may not, but forcing them to for no particular
gain they'll see is pretty narrow minded if you ask me.


>To make their lives easier all you need do is provide an additional
>check-box in the sysinst process which will automatically upgrade all of
>their packages for them.

What if I don't want them upgraded? What if I like foo 5.0.0 which I happen
to have installed and the current pkgsrc version is 5.7.0 which isn't "quite"
the same? By your logic I'm just SOL...


>The rest of the users might groan a bit, but they'd recompile and get on
>with more important things.  Maybe some of them would join the ranks of
>the first group.  Either way I think they'd be happier in the long run.

That's an awfully large asumption to rathole every possible user into. 
The idea is to give them choices, not force them into "Greg's NetBSD system".

>Remember too I (and kre, and I think greywolf, mcr, and others too) are
>still only talking about breaking such backwards compatability with
>MAJOR new releases, not minor ones.

And since you wouldn't have to worry about any of the shlib coordination
or would be just happy to recompile the entire system you're ok...But that's
not necessarily everyones view...

>
>The bottom line is that libc major bumps really should be made a part of
>the regular release process.  The very fact of becoming a regular part
>of the process would make it easier for users to plan for, as well as
>easier for the developers to plan for and to do on subsequent cycles.
>

See my comments above about providing choices on upgrade paths....

James