On Sun, Jun 03, 2007 at 10:51:24PM +0200, Pierre Habouzit <[EMAIL PROTECTED]> wrote: > On Sun, Jun 03, 2007 at 07:52:40PM +0200, Josselin Mouette wrote: > > Le dimanche 03 juin 2007 à 19:32 +0200, Raphael Hertzog a écrit : > > > Pierre explained that a sane library maintainer could/would use a new > > > version associated to the symbol even the ABI hasn't changed so that any > > > application linked against the newer version get to effectively depend > > > on the new version. > > > > I'm afraid we could count the number of libraries that use a per-symbol > > versioning scheme with a single hand. > > Of a guy that had many fingers amputated. > > > > On the contrary, with my mecanism if a new symbol appear it's > > > automatically associated to the new release. Thus it's no more possible > > > to "miss new symbols and forget to bump the shlibs". I really think that > > > on the whole, it will be way better than the current situation. > > > > It will surely be better for a majority of packages, and it is going to > > completely break a minority. It is not possible to rely on maintainers > > who don't really understand all the ways an ABI can change to tell > > whether this or that symbol has changed. I wouldn't trust myself to do > > that over a long time for all my own packages, at least. > > FWIW I don't really think it'll break a lot of one, and this minority > could be flagged not-for-buxy's-tool. What worries me more is the big > amount of let's say (completely at random) C++ libraries that do not use > symbols visibility, hence exposing myriad of non exported symbols, which > will create new shlib bumps for ... nothing.
Actually, the bump would only occur if the symbol get used... which wouldn't be a problem. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]