Re: HEADS UP: compat6x

On Sun, Dec 03, 2006 at 06:12:33AM -0600, Astrodog wrote:
> On 12/3/06, John Hay <jhay_at_meraka.org.za> wrote:
> >
> >On Sat, Dec 02, 2006 at 11:56:59PM -0800, Doug Barton wrote:
> >> John Hay wrote:
> >> > But even in all those other threads, never had there been a decent
> >> > answer why it is good to have two incompatible libraries with the same
> >> > number. It can only cause hurt.
> >>
> >> No one has said that it won't be changed, only that it won't be
> >> changed right this minute. It's ok if you don't understand all the
> >> technical points that were made in the previous threads (I don't
> >> understand them all either). But what you should realize is that this
> >> is -current, and sometimes stuff breaks. If you can't deal with that,
> >> run RELENG_6. Sorry to be so direct about it, but seriously ...
> >
> >Yes I can run something else than -current... I should also be able
> >to lobby for something if it looks like it can be better?
> >
> >I understand that there is churn (especially in the libs) in -current.
> >I don't have anything against it.
> >
> >I know the lib version numbers will be bumped. I'm happy with it.
> >
> >I'm just trying to reason that it should first be the version number
> >bump and then the lib churn.
> >
> >For the guy that have all the source and regularly recompile everything,
> >there is no change and he can still do that. What it does buy us, is that
> >RELENG_6 apps stay working and if people have apps that they do not have
> >the source for, they can still use it.
> >
> >It doesn't seem so unreasonable to just swap the order of things that
> >have to be done in any case? Or is unreasonable?
> >
> >John
> >
> 
> The problem with this idea, among other things, is that at times, during the
> development of -CURRENT, you'd be bumping libs every few hours. Since its
> impossible to garuntee that a lib will remain compatible, under all
> circumstances, its only handled as a best effort thing.

I did not mean you have to keep bumping the version numbers. You only
need to do it once for a lib. Only the first time it becomes incompatible
with what is in a release. I just propose we bump it early, so that the
churn happens in the new version and not in the old version which is also
being used by our previous release.

To show it with an example, if we make 6.0 with libpthread.so.2, then in
-current the first time we want change it to be incompatible, we first
change the version number and then make the changes. That way even people
running and rebuilding -current never sits with a libpthread.so.2 that is
incompatible with what is in 6.0 (or RELENG_6).

The way we do now, we first "contaminate" libpthread.so.2 and then at
some stage later before the next release, we bump the version in any
case. And people that rebuild their systems will sit with two files
libpthread.so.2 and libpthread.so.3, which is pretty much the same, but
both are incompatible with the libpthread.so.2 that shipped in 6.0.

The end result for people that just go from version to version is the
same and they won't notice the diference.

For people that recompile all of fbsd and all ports every time there
is no difference either. The difference is only for people that either
do not want to or cannot recompile all the apps that they use... or
maybe just do not want to recompile all their ports on the same day
as when they rebuilt their kernel and world(fbsd).

John
-- 
John Hay -- John.Hay_at_meraka.csir.co.za / jhay_at_FreeBSD.org