Re: HEADS UP: compat6x

Quoting Daniel Eischen <deischen@xxxxxxxxxxx> (from Tue, 5 Dec 2006 18:22:41 -0500 (EST)):

On Tue, 5 Dec 2006, John Baldwin wrote:

Yes, but it doesn't hurt to just bump things now. I actually agree with
John's argument that it is beneficial to allow folks on current to safely
use -stable apps by doing the library bump at first breakage. Granted, after
7.0 that policy will be obsolete, but it is still relevant for 7-current. :)
Heck, why not just enable symbol versioning in current by default now
anyways?

I'm waiting until after the GCC import because that should
change the way dependencies are recorded in shared libraries,
which really would force everyone to rebuild everything all
over again. After the GCC import, we should bump all the
libraries and enable symbol versioning, and hopefully you'll
only have to rebuild things once.

We have several upcomming stuff which ideally should be coordinated here. The symbol versioning (and the corresponding bump of the version of some libs) results in the need to rebuild everything, and the import of X.org 7.x would result in the need to rebuild some ports (when an user wants to update). I don't know if the import of gcc4 will need a rebuild of everything too.

Could all involved people please speak with each other (or tell us you did already) and try to coordinate a little bit?

Bye,
Alexander.

--
People are beginning to notice you.
Try dressing before you leave the house.

http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: HEADS UP: compat6x
    ... use -stable apps by doing the library bump at first breakage. ... why not just enable symbol versioning in current by default now ... change the way dependencies are recorded in shared libraries, ... only have to rebuild things once. ...
    (freebsd-current)
  • Re: libpthread shared library version number
    ... the line of what we have for other system libraries. ... We certainly should be bumping them ... would have to bump them again before a release, ... we should enable symbol versioning at ...
    (freebsd-current)
  • Re: Shared library version bump?
    ... :>> In preparation for release of 7.0, ... Hopefully this will be the last major bump for a long time... ... why bother with symbol versioning at all... ... If other libraries become symbol versioned after 7.0 gets ...
    (freebsd-current)
  • Re: libpthread shared library version number
    ... the line of what we have for other system libraries. ... We certainly should be bumping them ... would have to bump them again before a release, ... we should enable symbol versioning at ...
    (freebsd-current)
  • Re: libpthread shared library version number
    ... we should enable symbol versioning at ... The only reason for this bump is to allow binaries compiled for -STABLE to run on -CURRENT, which is not currently possible in the case when binary uses pthreads lib. ... shared library to other shared libraries. ...
    (freebsd-current)
Quantcast