On Mon, Jun 18, 2007 at 12:01:23PM +0200, Loïc Minier wrote:
> On Mon, Jun 18, 2007, Mike Hommey wrote:
> > It's even worse. You're acting as if you were modifying debian/symbols
> > without modifying it, saying it's fine because you didn't modify it...
> I think this is fine; the resulting "symb
Le lundi 18 juin 2007 à 10:08 +0100, Raphael Hertzog a écrit :
> The file in debian is *not* updated, that's precisely the point of this
> discussion. Joss wants the maintainer to update it beforehand, I let the
> maintainer update it after its final build but it will then be used only
> for the ne
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> On Mon, 18 Jun 2007, Goswin von Brederlow wrote:
>> > The file in debian is *not* updated, that's precisely the point of this
>> > discussion. Joss wants the maintainer to update it beforehand, I let the
>> > maintainer update it after its final build
* Loïc Minier ([EMAIL PROTECTED]) [070618 12:04]:
> On Mon, Jun 18, 2007, Mike Hommey wrote:
> > It's even worse. You're acting as if you were modifying debian/symbols
> > without modifying it, saying it's fine because you didn't modify it...
>
> I think this is fine; the resulting "symbols" file
* Raphael Hertzog ([EMAIL PROTECTED]) [070618 11:36]:
> On Mon, 18 Jun 2007, Mike Hommey wrote:
> > > The generated file is updated... and the file in the source package
> > > doesn't need to be updated so often. Additionnaly you can avoid having to
> > > rebuild once knowing that it will fail... l
On Mon, 18 Jun 2007, Mike Hommey wrote:
> It's even worse. You're acting as if you were modifying debian/symbols
> without modifying it, saying it's fine because you didn't modify it...
I have full control on the kind of changes that I allow in the
generated symbols file compared to the provided f
On Mon, 18 Jun 2007, Goswin von Brederlow wrote:
> > The file in debian is *not* updated, that's precisely the point of this
> > discussion. Joss wants the maintainer to update it beforehand, I let the
> > maintainer update it after its final build but it will then be used only
> > for the next upl
On Mon, Jun 18, 2007, Mike Hommey wrote:
> It's even worse. You're acting as if you were modifying debian/symbols
> without modifying it, saying it's fine because you didn't modify it...
I think this is fine; the resulting "symbols" file can make strict
assumptions.
You don't expect dh_makeshl
On Mon, Jun 18, 2007 at 10:08:36AM +0100, Raphael Hertzog <[EMAIL PROTECTED]>
wrote:
> On Mon, 18 Jun 2007, Mike Hommey wrote:
> > > The generated file is updated... and the file in the source package
> > > doesn't need to be updated so often. Additionnaly you can avoid having to
> > > rebuild onc
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> On Mon, 18 Jun 2007, Mike Hommey wrote:
>> > The generated file is updated... and the file in the source package
>> > doesn't need to be updated so often. Additionnaly you can avoid having to
>> > rebuild once knowing that it will fail... let the build
On Mon, 18 Jun 2007, Mike Hommey wrote:
> > The generated file is updated... and the file in the source package
> > doesn't need to be updated so often. Additionnaly you can avoid having to
> > rebuild once knowing that it will fail... let the build update the
> > generated file, get the diff from
On Mon, Jun 18, 2007 at 09:50:48AM +0100, Raphael Hertzog <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> On Mon, 18 Jun 2007, Josselin Mouette wrote:
> > Le dimanche 17 juin 2007 à 15:00 +0100, Raphael Hertzog a écrit :
> > > - we have different levels of check that can make dpkg-gensymbols fail
> > > (w
Hi,
On Mon, 18 Jun 2007, Josselin Mouette wrote:
> Le dimanche 17 juin 2007 à 15:00 +0100, Raphael Hertzog a écrit :
> > - we have different levels of check that can make dpkg-gensymbols fail
> > (with option -c). By default level 1 is activated, it will fail
> > if some symbols disappeared. L
Le dimanche 17 juin 2007 à 15:00 +0100, Raphael Hertzog a écrit :
> - we have different levels of check that can make dpkg-gensymbols fail
> (with option -c). By default level 1 is activated, it will fail
> if some symbols disappeared. Level 2 will also fail if new symbols are
> introduced wi
* Raphael Hertzog ([EMAIL PROTECTED]) [070617 18:15]:
> if some symbols disappeared. Level 2 will also fail if new symbols are
> introduced with prior update of the debian/symbols file. Level 3 and 4
^ without
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
--
To UNSUB
On Tue, 12 Jun 2007, Raphael Hertzog wrote:
> On Thu, 07 Jun 2007, Raphael Hertzog wrote:
> > Otherwise, the discussions in this thread lead to several interesting
> > points (listed in the TODO in the repository) which will require some
> > rewrite and optimization of the format of the symbols fil
On Thu, 07 Jun 2007, Raphael Hertzog wrote:
> Otherwise, the discussions in this thread lead to several interesting
> points (listed in the TODO in the repository) which will require some
> rewrite and optimization of the format of the symbols file. I'll update
> the wiki page and my implementation
On Thu, 07 Jun 2007, Steve Langasek wrote:
> Or are you questioning that most libraries ought to be using version
> scripts? I said they ought to, not that they currently did; and using
Yeah, that. Apparently my english failed me, and I didn't parse what you
meant correctly.
I am all for symbol
Le jeudi 07 juin 2007 à 20:44 +0200, Pierre Habouzit a écrit :
> symbol visibility support in gcc is not that old, and many upstream
> don't use it (yet).
libtool has supported -export-symbols since 1998 and
-export-symbols-regex since 1999.
> For them there is many many many private symbols in
On Thu, 07 Jun 2007, Russ Allbery wrote:
> There's an argument to be made that shlibs files should be provided by the
> -dev packages, not the library packages. We should at least think about
> whether the symbols files belong in the -dev package. They're used to
> generate dependencies for packa
* Julien Cristau ([EMAIL PROTECTED]) [070607 18:04]:
> On Thu, Jun 7, 2007 at 17:56:46 +0200, Andreas Barth wrote:
>
> > * Mike Hommey ([EMAIL PROTECTED]) [070607 17:49]:
> > > On Thu, Jun 07, 2007 at 05:39:56PM +0200, Andreas Barth <[EMAIL
> > > PROTECTED]> wrote:
> > > > symbols MUST NEVER dis
Mike Hommey <[EMAIL PROTECTED]> writes:
> Raphael Hertzog <[EMAIL PROTECTED]> wrote:
>> Otherwise, the discussions in this thread lead to several interesting
>> points (listed in the TODO in the repository) which will require some
>> rewrite and optimization of the format of the symbols file. I'll
On Thu, Jun 07, 2007 at 10:28:35PM +0200, Raphael Hertzog <[EMAIL PROTECTED]>
wrote:
> Otherwise, the discussions in this thread lead to several interesting
> points (listed in the TODO in the repository) which will require some
> rewrite and optimization of the format of the symbols file. I'll up
On Thu, Jun 07, 2007 at 11:23:18PM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 07 Jun 2007, Steve Langasek wrote:
> > It's been possible to avoid the export of symbols for years using version
> > scripts, which most libraries also ought to be using anyway.
> Maybe on Solaris. On Linux? Who
On Thu, Jun 07, 2007 at 06:03:49PM +0200, Julien Cristau wrote:
> On Thu, Jun 7, 2007 at 17:56:46 +0200, Andreas Barth wrote:
> > * Mike Hommey ([EMAIL PROTECTED]) [070607 17:49]:
> > > On Thu, Jun 07, 2007 at 05:39:56PM +0200, Andreas Barth <[EMAIL
> > > PROTECTED]> wrote:
> > > > symbols MUST
On Thu, 07 Jun 2007, Steve Langasek wrote:
> It's been possible to avoid the export of symbols for years using version
> scripts, which most libraries also ought to be using anyway.
Maybe on Solaris. On Linux? Who are you kidding?
--
"One disk to rule them all, One disk to find them. One disk
On Thu, Jun 07, 2007 at 08:44:32PM +0200, Pierre Habouzit wrote:
> On Thu, Jun 07, 2007 at 07:15:22PM +0200, Bernhard R. Link wrote:
> > * Julien Cristau <[EMAIL PROTECTED]> [070607 18:04]:
> > > > Reality is that this build must fail with a proper warning, so that the
> > > > maintainer can decide
Hello,
On Mon, 04 Jun 2007, Raphael Hertzog wrote:
> What comes next
> ---
> Up to now, I only tested those scripts on a few packages. What comes next
> is some archive-wide work:
> - I want to generate ready-to-use symbols file for all libraries
> initialized with packages from etch
On Thu, Jun 07, 2007 at 07:15:22PM +0200, Bernhard R. Link wrote:
> * Julien Cristau <[EMAIL PROTECTED]> [070607 18:04]:
> > > Reality is that this build must fail with a proper warning, so that the
> > > maintainer can decide if this is an excption and ok or whether he should
> > > cluebat upstrea
On Thu, 7 Jun 2007 19:15:22 +0200, Bernhard R Link <[EMAIL PROTECTED]> said:
> * Julien Cristau <[EMAIL PROTECTED]> [070607 18:04]:
>> > Reality is that this build must fail with a proper warning, so that
>> > the maintainer can decide if this is an excption and ok or whether
>> > he should clueb
Raphael Hertzog wrote:
> I double-checked this and no, it's not the case. Extract from dpkg-shlibdeps:
> while () {
> s/\s*\n$//; next if m/^\#/;
> if (!m/^\s*(?:(\S+):\s+)?(\S+)\s+(\S+)/) {
> &warn(sprintf(_g("shared libs info file \`%s' line %d: bad line
> \`%s'")
* Julien Cristau <[EMAIL PROTECTED]> [070607 18:04]:
> > Reality is that this build must fail with a proper warning, so that the
> > maintainer can decide if this is an excption and ok or whether he should
> > cluebat upstream about a what soname means.
> >
> Reality is that libs export private sym
Raphael Hertzog wrote:
> For me the only significant advantage of this proposed format is that it
> offers the possibility to add additional automatic dependencies at the
> package level and not only at the symbol level.
>
> Joey, how would you integrate this new scheme if I decided to reuse the
>
On Thu, Jun 7, 2007 at 17:56:46 +0200, Andreas Barth wrote:
> * Mike Hommey ([EMAIL PROTECTED]) [070607 17:49]:
> > On Thu, Jun 07, 2007 at 05:39:56PM +0200, Andreas Barth <[EMAIL PROTECTED]>
> > wrote:
> > > symbols MUST NEVER disappear!
> >
> > Reality is that it happens.
>
> Reality is that
* Mike Hommey ([EMAIL PROTECTED]) [070607 17:49]:
> On Thu, Jun 07, 2007 at 05:39:56PM +0200, Andreas Barth <[EMAIL PROTECTED]>
> wrote:
> > > The real lib has precedence over the provided symbols file.
> > > - any new symbol is added and marked with mininal version being the
> > > current
> > >
On Thu, Jun 07, 2007 at 05:39:56PM +0200, Andreas Barth <[EMAIL PROTECTED]>
wrote:
> > The real lib has precedence over the provided symbols file.
> > - any new symbol is added and marked with mininal version being the current
> > version of the package
> > - a symbol that disappeared is marked
* Raphael Hertzog ([EMAIL PROTECTED]) [070606 14:03]:
> On Wed, 06 Jun 2007, Steve Langasek wrote:
> > On Wed, Jun 06, 2007 at 09:15:02AM +0200, Raphael Hertzog wrote:
> > > Now, if we have people store symbols in shlibs file, it means that
> > > dh_installdeb would install the shlibs file with sym
On Thu, Jun 07, 2007 at 09:05:23AM +0200, Raphael Hertzog wrote:
> On Wed, 06 Jun 2007, Steve Langasek wrote:
> > > Can you expand? I don't see at all how libgl would "benefit" from this new
> > > approach. The current shlibs is already very lax and non-versioned.
> > Yes, and that's the problem:
Le jeudi 07 juin 2007 à 09:05 +0200, Raphael Hertzog a écrit :
> > Yes, and that's the problem: I know the libgl shlibs to have been wrong in
> > certain corner cases involving uncommon symbols (whether those are
> > implementors adding their own extensions, or failing to implement the
> > standar
On Wed, 06 Jun 2007, Steve Langasek wrote:
> > Can you expand? I don't see at all how libgl would "benefit" from this new
> > approach. The current shlibs is already very lax and non-versioned.
>
> Yes, and that's the problem: I know the libgl shlibs to have been wrong in
> certain corner cases i
On Wed, Jun 06, 2007 at 02:33:58PM +0200, Raphael Hertzog wrote:
> On Wed, 06 Jun 2007, Steve Langasek wrote:
> > > > Consider cases where you want to declare that more than one package
> > > > satisfies the dependency -- we do have libraries using that today in
> > > > their
> > > > shlibs. I do
On Wed, Jun 06, 2007 at 09:53:41PM +0200, Kurt Roeckx wrote:
> On Wed, Jun 06, 2007 at 07:55:28PM +0200, Julien Cristau wrote:
> > On Wed, Jun 6, 2007 at 17:50:26 +, Oleg Verych wrote:
> > > Just as better alternative IMHO, please consider using `eu-readelf -ds`
> > > from elfutils.
> > elfu
* From: Julien Cristau
> Newsgroups: gmane.linux.debian.devel.general
>
> On Wed, Jun 6, 2007 at 17:50:26 +, Oleg Verych wrote:
>
>> Just as better alternative IMHO, please consider using `eu-readelf -ds`
>> from elfutils.
>
> elfutils isn't build-essential. binutils is, and does the job, so "
On Wed, Jun 06, 2007 at 07:55:28PM +0200, Julien Cristau wrote:
> On Wed, Jun 6, 2007 at 17:50:26 +, Oleg Verych wrote:
>
> > Just as better alternative IMHO, please consider using `eu-readelf -ds`
> > from elfutils.
>
> elfutils isn't build-essential. binutils is, and does the job, so "it's
On Wed, Jun 6, 2007 at 17:50:26 +, Oleg Verych wrote:
> Just as better alternative IMHO, please consider using `eu-readelf -ds`
> from elfutils.
elfutils isn't build-essential. binutils is, and does the job, so "it's
better IMHO" isn't a particularly compelling reason to make all packages
bu
* From: Steve Langasek
* Date: Wed, 6 Jun 2007 03:34:59 -0700
[]
> FWIW, in the prototyping I did in the unixodbc package I made the symbol
> version and the symbol name two separate fields separated by whitespace,
> because this made it easier to generate files of this format with objdump -T
> and
On Wed, 06 Jun 2007, Loïc Minier wrote:
> On Wed, Jun 06, 2007, Raphael Hertzog wrote:
> > We could then have the package field contain multiple packages (separated
> > by "," or "|" or whatever) and have dpkg-shlibdeps generate pkg1 (>=
> > min-ver) | pkg2 (>= min-ver).
>
> I don't think so; at
On Wed, 06 Jun 2007, Steve Langasek wrote:
> > > Consider cases where you want to declare that more than one package
> > > satisfies the dependency -- we do have libraries using that today in their
> > > shlibs. I do think it's necessary here to support the full range of
> > > dependency semantics
On Wed, 06 Jun 2007, Steve Langasek wrote:
> On Wed, Jun 06, 2007 at 09:15:02AM +0200, Raphael Hertzog wrote:
> > Now, if we have people store symbols in shlibs file, it means that
> > dh_installdeb would install the shlibs file with symbols. That could be
> > almost enough except that we really wa
On Wed, Jun 06, 2007 at 01:42:55PM +0200, Raphael Hertzog wrote:
> On Wed, 06 Jun 2007, Steve Langasek wrote:
> > > It would be much more worth to drop the package name from the
> > > dependencies. Except a few corner cases (which could probably be
> > > worked around some other way), they are alwa
On Wed, Jun 06, 2007, Raphael Hertzog wrote:
> We could then have the package field contain multiple packages (separated
> by "," or "|" or whatever) and have dpkg-shlibdeps generate pkg1 (>=
> min-ver) | pkg2 (>= min-ver).
I don't think so; at least sometimes you want to depend on
non-versionne
On Wed, 06 Jun 2007, Steve Langasek wrote:
> > It would be much more worth to drop the package name from the
> > dependencies. Except a few corner cases (which could probably be
> > worked around some other way), they are always the package name
> > inside which the library is...
>
> > The >= is a
On Wed, Jun 06, 2007 at 09:53:22AM +0200, Raphael Hertzog wrote:
> What you propose would look like:
> libc 6
> [EMAIL PROTECTED] libc6 2.3.6.ds1-13
> [EMAIL PROTECTED] libc6 2.3.6.ds1-13
> Because of the "^\s*" you can't use starting spaces as a differentiating
> factor. The lines wit
On Wed, Jun 06, 2007 at 09:15:02AM +0200, Raphael Hertzog wrote:
> Now, if we have people store symbols in shlibs file, it means that
> dh_installdeb would install the shlibs file with symbols. That could be
> almost enough except that we really want a check that the information
> stored in those f
On Tue, Jun 05, 2007 at 08:14:18PM +0200, Mike Hommey wrote:
> On Tue, Jun 05, 2007 at 02:02:59PM -0400, Joey Hess <[EMAIL PROTECTED]> wrote:
> > [1] #363133
> > [2] Would it be worthwhile to support multiple symbols on one line to
> > save even more space?
> > symbol [symbol...] de
On Tue, Jun 05, 2007 at 02:02:59PM -0400, Joey Hess <[EMAIL PROTECTED]> wrote:
> [1] #363133
> [2] Would it be worthwhile to support multiple symbols on one line to
> save even more space?
> symbol [symbol...] dependencies...
It would be much more worth to drop the package name from the
On Tue, 05 Jun 2007, Joey Hess wrote:
> It seems that this could be extended to include symbol information:
>
> [package-type:] library-name soname-version-number dependencies...
> [symbol dependencies...]
> [...]
>
> Like the package-type extension, this extra information will be
> t
On Tue, 05 Jun 2007, Joey Hess wrote:
> Note that policy doesn't fully document[1] the current shlibs format,
> which is:
>
> [package-type:] library-name soname-version-number dependencies...
>
> It seems that this could be extended to include symbol information:
>
> [package-type:] library-nam
Peter Samuelson <[EMAIL PROTECTED]> writes:
> [Russ Allbery]
>> They *usually* do, but not all E tags are certain problems. Of course,
>> maintainers could use overrides.
> I'm opposed to adding overrides to my packages for cases where, in my
> view, lintian should somehow have enough informatio
[Russ Allbery]
> They *usually* do, but not all E tags are certain problems. Of course,
> maintainers could use overrides.
I'm opposed to adding overrides to my packages for cases where, in my
view, lintian should somehow have enough information to see the case as
a false positive. I use them o
Felipe Sateler <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> The primary barrier to enforcing the use of lintian is #243976. lintian
>> needs to get much better about identifying the source of checks, the
>> certainty that something is wrong, and the severity level so that dak
>> can run li
Steve Langasek wrote:
> On Tue, Jun 05, 2007 at 04:47:07PM -0400, Felipe Sateler wrote:
>
>> > Throwing a sensible error at build-time if the soname has changed
>> > without a package name change is also something that needs to be done,
>> > as well as throwing an error at build-time if symbols l
Russ Allbery wrote:
> Felipe Sateler <[EMAIL PROTECTED]> writes:
>
>> What you want may be achieved by enforcing the use of lintian, but I
>> don't know how that can be done.
>
> The primary barrier to enforcing the use of lintian is #243976. lintian
> needs to get much better about identifying
On Tue, Jun 05, 2007 at 04:47:07PM -0400, Felipe Sateler wrote:
> > Throwing a sensible error at build-time if the soname has changed without
> > a package name change is also something that needs to be done, as well as
> > throwing an error at build-time if symbols listed in the symbols file have
Felipe Sateler <[EMAIL PROTECTED]> writes:
> What you want may be achieved by enforcing the use of lintian, but I
> don't know how that can be done.
The primary barrier to enforcing the use of lintian is #243976. lintian
needs to get much better about identifying the source of checks, the
certai
Steve Langasek wrote:
> Throwing a sensible error at build-time if the soname has changed without
> a package name change is also something that needs to be done, as well as
> throwing an error at build-time if symbols listed in the symbols file have
> gone missing;
Lintian already does the firs
Steve Langasek wrote:
> > Finally, why not add the symbol informations to the shlibs file (that
> > can be done in a backwards compatible way) instead of creating yet
> > another control file ?
>
> I'd rather we didn't, even if it doesn't break anything it still abuses the
> shlibs file format as
[Josselin Mouette]
> A possible part of the solution would be a script parsing the diff
> between headers and emitting warnings such as:
> * type foo has changed, please check it doesn't affect functions
> bar/baz/...
> * enum foo has new possible values, please check it doesn'
* From: Steve Langasek
* Date: Tue, 5 Jun 2007 02:56:14 -0700
>
> On Tue, Jun 05, 2007 at 08:56:40AM +0200, Raphael Hertzog wrote:
>> On Mon, 04 Jun 2007, Steve Langasek wrote:
[]
>> > Considering the number of bugs I see because of maintainers who don't
>> > notice
>> > they need to change packag
Loïc Minier <[EMAIL PROTECTED]> writes:
> On Mon, Jun 04, 2007, Raphael Hertzog wrote:
>> Library maintainers are supposed to maintain the *.symbols file. For
>> this, they have to create files "debian/.symbols."
>> (dpkg-gensymbols will try too fallback to "debian/symbols.",
>> "debian/.symbols"
On Tue, Jun 05, 2007 at 08:07:20AM +0200, Mike Hommey wrote:
> On Mon, Jun 04, 2007 at 02:32:10PM -0700, Steve Langasek <[EMAIL PROTECTED]>
> wrote:
> > On Mon, Jun 04, 2007 at 10:29:07PM +0200, Josselin Mouette wrote:
> > > Le lundi 04 juin 2007 à 21:29 +0200, Raphael Hertzog a écrit :
> > > > >
On Tue, Jun 05, 2007 at 08:56:40AM +0200, Raphael Hertzog wrote:
> On Mon, 04 Jun 2007, Steve Langasek wrote:
> > On Mon, Jun 04, 2007 at 10:29:07PM +0200, Josselin Mouette wrote:
> > > I agree that the benefits are worth the deal, but we should make clear
> > > that the price to pay for these bene
On Mon, 04 Jun 2007, Steve Langasek wrote:
> On Mon, Jun 04, 2007 at 10:29:07PM +0200, Josselin Mouette wrote:
> > I agree that the benefits are worth the deal, but we should make clear
> > that the price to pay for these benefits is a continuous effort from the
> > maintainer. Therefore it should
On Mon, Jun 04, 2007 at 02:32:10PM -0700, Steve Langasek <[EMAIL PROTECTED]>
wrote:
> On Mon, Jun 04, 2007 at 10:29:07PM +0200, Josselin Mouette wrote:
> > Le lundi 04 juin 2007 à 21:29 +0200, Raphael Hertzog a écrit :
> > > > Again, this doesn't take into account existing symbols that change thei
On Mon, Jun 04, 2007 at 10:29:07PM +0200, Josselin Mouette wrote:
> Le lundi 04 juin 2007 à 21:29 +0200, Raphael Hertzog a écrit :
> > > Again, this doesn't take into account existing symbols that change their
> > > ABI across versions. I won't insist too much, as I have already
> > > explained at
Le lundi 04 juin 2007 à 21:29 +0200, Raphael Hertzog a écrit :
> > Again, this doesn't take into account existing symbols that change their
> > ABI across versions. I won't insist too much, as I have already
> > explained at large how heavy a burden it puts on the maintainer's
> > shoulders.
>
> I
On Mon, 04 Jun 2007, Josselin Mouette wrote:
> Le lundi 04 juin 2007 à 10:54 +0200, Raphael Hertzog a écrit :
> > Creating a first version of the symbols file is not difficult either. For
> > the sake of example, here's how I did with the libc6 package. I included
> > the etch package first so tha
Le lundi 04 juin 2007 à 21:13 +0200, Raphael Hertzog a écrit :
> We could create a .symbols-udeb however... we just need to scan the
> udeb during build and put the resulting symbols file in the main library.
> That wouldn't be too difficult to do. We can probably keep this as
> extension for the f
On Mon, 04 Jun 2007, Josselin Mouette wrote:
> Le lundi 04 juin 2007 à 12:27 +0200, Raphael Hertzog a écrit :
> > 2/ dpkg-shlibdeps does follow executable -> library -> package ->
> > /var/lib/dpkg/info/.{shlibs,symbols} to find out the
> > dependencies. However with udebs the step "library -> pack
Le lundi 04 juin 2007 à 10:54 +0200, Raphael Hertzog a écrit :
> Creating a first version of the symbols file is not difficult either. For
> the sake of example, here's how I did with the libc6 package. I included
> the etch package first so that I have history of symbols starting from
> etch.
>
Le lundi 04 juin 2007 à 12:27 +0200, Raphael Hertzog a écrit :
> 2/ dpkg-shlibdeps does follow executable -> library -> package ->
> /var/lib/dpkg/info/.{shlibs,symbols} to find out the
> dependencies. However with udebs the step "library -> package" can't be
> done with "dpkg --search" (it's curre
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 <[EMAIL
> > PROTECTED]> wrote:
> > > Library maintainers who want to avoid any mistakes can use the "-c" option
> > > (for compare)
On Mon, 04 Jun 2007, Loïc Minier wrote:
> On Mon, Jun 04, 2007, Raphael Hertzog wrote:
> > While I agree on the burden, I don't think it's wise to rely on other
> > tools to merge multiple informations in a single file which would then be
> > given to dpkg-gensymbols.
>
> Hmm, how is this differe
On Mon, Jun 04, 2007, Raphael Hertzog wrote:
> While I agree on the burden, I don't think it's wise to rely on other
> tools to merge multiple informations in a single file which would then be
> given to dpkg-gensymbols.
Hmm, how is this different from the way *.shlibs files are handled
currentl
On Mon, 04 Jun 2007, Loïc Minier wrote:
> On Mon, Jun 04, 2007, Raphael Hertzog wrote:
> > Library maintainers are supposed to maintain the *.symbols file. For
> > this, they have to create files "debian/.symbols."
> > (dpkg-gensymbols will try too fallback to "debian/symbols.",
> > "debian/.symbo
On Mon, Jun 04, 2007, Raphael Hertzog wrote:
> Library maintainers are supposed to maintain the *.symbols file. For
> this, they have to create files "debian/.symbols."
> (dpkg-gensymbols will try too fallback to "debian/symbols.",
> "debian/.symbols" and "debian/symbols"). They are
> required to
On Mon, 04 Jun 2007, Mike Hommey wrote:
> On Mon, Jun 04, 2007 at 10:54:30AM +0200, Raphael Hertzog <[EMAIL PROTECTED]>
> 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 d
On Mon, Jun 04, 2007 at 10:54:30AM +0200, Raphael Hertzog <[EMAIL PROTECTED]>
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 c
[Bcc on [EMAIL PROTECTED] so that discussion happens on -devel]
Hello,
I've gone forward with the plan that I exposed in
http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps
Please grab the code with:
$ bzr get http://bzr.debian.org/private/hertzog/shlibdeps/
The repository contains two scrip
89 matches
Mail list logo
