Previously Matthew Vernon wrote:
> Which error are you referring to?
Please see the REJECT message you got from dinstall, that has a full
explanation.
Wichert.
--
/ Generally uninteresting signature - ignore at your convenienc
On Wed, Jan 19, 2000 at 03:56:15PM +0100, Wichert Akkerman wrote:
> Package: debian-policy
>
> In woody dpkg will use a different method to determine on which
> libraries a package should depend. Until now dpkg-shlibdeps has
> used the output of ldd to determine which libraries are needed.
> This
Package: debian-policy
(This is being resend because the BTS apparently can't handle PGP/MIME
messages with attachments).
In woody dpkg will use a different method to determine on which
libraries a package should depend. Until now dpkg-shlibdeps has
used the output of ldd to determine which libra
On Wed, Jan 19, 2000 at 03:56:15PM +0100, Wichert Akkerman wrote:
> Package: debian-policy
>
> In woody dpkg will use a different method to determine on which
> libraries a package should depend. Until now dpkg-shlibdeps has
> used the output of ldd to determine which libraries are needed.
> This
> In woody dpkg will use a different method to determine on which
> libraries a package should depend. Until now dpkg-shlibdeps has used
> the output of ldd to determine which libraries are needed. This will
> be changed to using objdump.
[...]
> And now for the connection to package management: a
> 1) It allows for cross compilation (without the dpkg-shlibdeps
> replacement in dpkg-cross)
What Wichert wants is basically the objdump-based variant in
dpkg-cross. It does nothing else than he plans to do.
Aehm, wait, one change is needed: dpkg-cross' shlibdeps current
expects all libraries t
Wichert Akkerman writes:
> In woody dpkg will use a different method to determine on which
> libraries a package should depend. Until now dpkg-shlibdeps has
> used the output of ldd to determine which libraries are needed.
> This will be changed to using objdump. This however changes
> will n
[I think that some version of the original message should be posted at
some point to -devel-announce, probably once the new dpkg-shlibdeps is
installed in woody. We also might need some NMUs if this occurs
during the potato freeze and many developers are working on frozen
rather than unstable mach
> What about packages using debstd, or dpkg-gencontrol? I presume dpkg
> will be patched such that such packages will still build?
Hae? debstd can call dpkg-shlibdeps in the by Wichert says; no change
in the package itself. dpkg-gencontrol is totally independent. Any why
patch dpkg???
Roman
> How do we ensure that someone upgrading a package from potato to woody
> pulls in all of the required libraries? As a "concrete" example,
> /usr/bin/foo in the foo package depends upon libbar directly and
> libbar depends upon libbaz indirectly. In potato, libbar does not
> declare a dependenc
Previously Roman Hodek wrote:
> The problem you describe can exist. But only if libbar doesn't depend
> yet on libbaz in potato.
Right, and I'm willing to bet that happens. Not everyone uses
debhelper..
> However (as already said in a previous mail) I think that most shlib
> packages already do d
Previously Roman Hodek wrote:
> Don't most packages do this already? I guess at least debhelper and
> debstd should run dpkg-shlibdeps on libs already... So the change
> shouldn't affect too many packages.
Looking at the db_shlibdeps code it indeed does so already. I mostly
checked some GNOME stu
Previously Julian Gilbey wrote:
> [I think that some version of the original message should be posted at
> some point to -devel-announce, probably once the new dpkg-shlibdeps is
> installed in woody. We also might need some NMUs if this occurs
> during the potato freeze and many developers are wor
Previously Matthew Vernon wrote:
> What about packages using debstd, or dpkg-gencontrol? I presume dpkg
> will be patched such that such packages will still build?
You are completely misunderstanding what debstd and dpkg-gencontrol do.
dpkg-gencontrol *always* has to be called since it is what gen
> People using gtk and imlib are supposed to use gtk-config and
> imlib-config to get the right compile and link flags. Now look
> at this:
>
> [tornado;~/sources/original/dpkg/dpkg]-10> imlib-config --libs
> -L/usr/lib -lImlib -ljpeg -ltiff -lungif -lpng -lz -lm -lXext
> -L/usr/X11R6/lib -lSM -lIC
> Right, and I'm willing to bet that happens. Not everyone uses
> debhelper..
Sure, not everyone, but many. And not to forget, (AFAIK) debstd does
the same. Indeed, I always thought that shlib packages should depend
on the libs they need already... :-)
> I guess it could be done as a lintian che
> So imlib-config shouldn't list any of those libraries since libImlib
> is already linked to them.
I guess imlib-config lists those libraries for the case of static
libs. Then you don't have automatic link-in of secondary libs...
Roman
Previously Ronald van Loon wrote:
> This is not true. Direct dependencies and the libraries needed for
> compiling are two different things. Unless the linker has become
> extremely smart, it is still necessary to specify all libraries a
> program needs on the command line.
Then explain to my why
Previously Roman Hodek wrote:
> I guess imlib-config lists those libraries for the case of static
> libs. Then you don't have automatic link-in of secondary libs...
Hmm, valid point. Anyone care to harass the GNOME people into adding
--static and --dynamic options to *-config? :)
Wichert.
--
Greetings list. About a week ago, Julian posted a diff to policy, bu 55048,
and I sent an email of encouragement directly to Julian. Since that time, I
don't recall any other comments towards his diff, so I thought I would try
to help stir things up.
So, here is the email I have sent to Julian per
On Thu, Jan 20, 2000 at 02:35:33PM +0100, Wichert Akkerman wrote:
> Previously Julian Gilbey wrote:
> > [I think that some version of the original message should be posted at
> > some point to -devel-announce, probably once the new dpkg-shlibdeps is
> > installed in woody. We also might need some
On Thu, 20 Jan 2000, Roman Hodek wrote:
> However (as already said in a previous mail) I think that most shlib
> packages already do depend on other libs they need. What about
> checking for libs that have no such dependencies first?
It would be a nasty bug if this is not the case, consider doin
On Thu, 20 Jan 2000, Ronald van Loon wrote:
> This is not true. Direct dependencies and the libraries needed for
> compiling are two different things. Unless the linker has become
> extremely smart, it is still necessary to specify all libraries a
No, this is wrong. With dynamic linking it is pr
> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> Previously Ronald van Loon wrote:
>> This is not true. Direct dependencies and the libraries needed
>> for compiling are two different things. Unless the linker has
>> become extremely smart, it is still neces
On 21 Jan 2000, Brian May wrote:
> It doesn't seem to work for the Kerberos libraries. For instance,
> libcyrus-sasl needs to link in the gssapi library, from heimdal-lib.
>
> Ideally, putting -lgssapi on the command line would be good
> enough - it isn't. I get lots of symbol undefined errors.
> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Brian> I thought the solution was obvious - change the shared
Brian> library dependancy information on libbar
I meant to cancel this post, not send it! ARGGHHH!!!
Anyway, now I have sent it, I might as well complete what I was saying.
> "Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes:
Julian> How do we ensure that someone upgrading a package from
Julian> potato to woody pulls in all of the required libraries?
Julian> As a "concrete" example, /usr/bin/foo in the foo package
Julian> depends upon libbar di
On Thu, Jan 20, 2000 at 03:34:29PM +0100, Ronald van Loon wrote:
> program needs on the command line. While it may be true that it is
> sufficient to be *dependent* only on imlib, it is still necessary to
> specify all those other implicit libraries to the linker. The linker is
> not smart enough
28 matches
Mail list logo
