[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dependencies on shared libs, take 2



Le lundi 04 juin 2007 à 11:25 +0200, Raphael Hertzog a écrit :
> On Mon, 04 Jun 2007, Mike Hommey wrote:
> > On Mon, Jun 04, 2007 at 10:54:30AM +0200, Raphael Hertzog <hertzog@debian.org> wrote:
> > > Library maintainers who want to avoid any mistakes can use the "-c" option
> > > (for compare) which will make the compilation fail if the generated
> > > symbols file differ from the maintainer supplied file. In that case, the
> > > build log contains a diff between the two symbols files and he can analyze
> > > the differences (and update his file if necessary).
> > 
> > I think this should be the default behaviour.
> 
> Well, the default behaviour that I intended to use is somewhat different
> and more suited to small libraries maybe:
> 
> - the maintainer runs a script 'update-symbols' which downloads the latest
>   symbols files for all arches in debian/ from a central server which
>   extracts the symbols file from the last-built package.
> - the maintainer builds the new upstream package and the new symbol
>   information is auto-merged in the generated symbols file
> - go back to first step for the next version

I second Mike's request. It is important that this becomes the default
behavior, so that libraries fail to build on other architectures, where
the symbol list can be different.

> This scheme allows to simply follow the history of the package without
> complicating too much the life of the maintainer.
> 
> Furthermore non-versioned libraries export many private functions which
> can appear and disappear, and it shouldn't necessarily fail because of
> that. So this option is probably well suited for versioned libraries but
> too much hassle for non-versioned ones.

It seems normal to update the file manually when the library switches
some symbols to not be exported.

Cheers,
-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.

Attachment: signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=


Reply to: