On Thu, Nov 03, 2005 at 09:07:12AM -0800, Russ Allbery wrote:
> Like I said, this defeats the entire point of the FHS.
What is the "entire point" of the FHS? If it is to disallow alternative
implementations of the same interface to co-exist then the FHS is
broken. Fortunately, this is not my read
Gabor Gombas <[EMAIL PROTECTED]> writes:
> On Mon, Oct 31, 2005 at 11:15:35PM -0800, Russ Allbery wrote:
>> I don't consider this to be a good solution. #include is part
>> of the API, and forcing all packages that want to build with Kerberos
>> to use special compiler flags to find include file
On Mon, Oct 31, 2005 at 11:15:35PM -0800, Russ Allbery wrote:
> Speaking as a co-maintainer of libkrb5-dev, no, this Conflicts assumes
> that the two packages, er, conflict. Namely, they provide
> identically-named include files which define different ways of
> implementing roughly the same API.
Gabor Gombas <[EMAIL PROTECTED]> writes:
> libkrb5-dev Conflicts: heimdal-dev
> ==
> The problem here is that this "Conflicts:" assumes that the system has
> just one user, which is simply not true.
Speaking as a co-maintainer of libkrb5-dev, no, this Conflicts as
On Tue, Oct 25, 2005 at 07:15:29PM +0200, Kurt Roeckx wrote:
> Then I guess it's either not used properly most of the time,
> or hard they make it hard to use it properly.
That's right. Requres.private: is supported only since pkg-config-0.18,
and there are not many packages making use of it yet.
On Tue, Oct 25, 2005 at 04:29:20PM +0200, Gabor Gombas wrote:
> On Mon, Oct 24, 2005 at 07:55:25PM +0200, Kurt Roeckx wrote:
>
> > > $ pkg-config --libs a
> > > -la -lb
> > ^^^
> >
> > It should not link to libb if you only request it to link to
> > liba. liba should have a DT_NEEDED for l
On Mon, Oct 24, 2005 at 07:55:25PM +0200, Kurt Roeckx wrote:
> > $ pkg-config --libs a
> > -la -lb
> ^^^
>
> It should not link to libb if you only request it to link to
> liba. liba should have a DT_NEEDED for libb, and the linker
> should find the symbols liba needs from libb itself.
No
Gabor Gombas <[EMAIL PROTECTED]> writes:
> On Mon, Oct 24, 2005 at 07:13:02PM +0200, Goswin von Brederlow wrote:
>
>> That is indeed the problem. But how would a wraper help? You still
>> have to somehow tell the wraper if gcc will later be invoked with -m32
>> or -m64.
>
> Whatever build system y
On Mon, Oct 24, 2005 at 05:20:16PM -0200, Henrique de Moraes Holschuh wrote:
> > >
> > > $ pkg-config --libs a
> > > -la -lb
> > ^^^
> >
> > It should not link to libb if you only request it to link to
> > liba. liba should have a DT_NEEDED for libb, and the linker
> > should find the symb
On Mon, 24 Oct 2005, Kurt Roeckx wrote:
> On Mon, Oct 24, 2005 at 02:03:51PM +0200, Gabor Gombas wrote:
> > On Fri, Oct 21, 2005 at 07:15:38PM +0200, Kurt Roeckx wrote:
> > > Pretty please don't suggest that unless you first fix pkg-config.
> > > It's always linking in the libraries required for st
On Mon, 24 Oct 2005, Gabor Gombas wrote:
> > Unless packages ship the pkg-config binary itself. Even then, the Debian
> > mode could be dependent on dpkg-architecture existing or somesuch, so people
> > could still use Debian as upstream developers without hassle.
>
> I do not think pkg-config sh
On Mon, Oct 24, 2005 at 02:03:51PM +0200, Gabor Gombas wrote:
> On Fri, Oct 21, 2005 at 07:15:38PM +0200, Kurt Roeckx wrote:
>
> 3D
> > Pretty please don't suggest that unless you first fix pkg-config.
> > It's always linking in the libraries required for static linking
> > even if you don't reque
On Mon, Oct 24, 2005 at 07:13:02PM +0200, Goswin von Brederlow wrote:
> That is indeed the problem. But how would a wraper help? You still
> have to somehow tell the wraper if gcc will later be invoked with -m32
> or -m64.
Whatever build system you use, there must be some logic somewhere to
decid
I demand that Gabor Gombas may or may not have written...
> On Fri, Oct 21, 2005 at 02:15:28AM +0100, Darren Salt wrote:
>> I can see potential problems with that last part regarding upstream
>> developers whose software happens to depend on packages for which
>> pkg-config support remains Debian-
On Mon, Oct 24, 2005 at 12:37:41PM -0200, Henrique de Moraes Holschuh wrote:
> That said, it is sort of on-topic anyway. Can pkg-config be told which arch
> to build to? If it doesn't, it is high time to fix this, and it would fix
> the problem of getting .pc files to be installed to the right p
Gabor Gombas <[EMAIL PROTECTED]> writes:
> On Fri, Oct 21, 2005 at 10:24:11PM +0200, Goswin von Brederlow wrote:
>
>> The problem is that pc files are architecture dependent. With
>> multiarch there will be
>>
>> /usr/lib/i486-linux-gnu/glib.pc
>> /usr/lib/x86_64-linux-gnu/glib.pc
>
> Well, pkg-c
On Mon, 24 Oct 2005, Gabor Gombas wrote:
> Who talked about _arch_ autodetection? I think the discussion was about
Sorry, my bad. I thought that mentioning "arch" and "configure" and
"auto-detection" in the same post meant the kind of runtime arch
autodetection buggy debian packages (and non-buggy
On Mon, Oct 24, 2005 at 10:36:08AM -0200, Henrique de Moraes Holschuh wrote:
> May I humbly remind people that allowing any sort of arch autodetection in
> a Debian package build *IS* *A* *BUG*.
Who talked about _arch_ autodetection? I think the discussion was about
packages that previously only
On Mon, 24 Oct 2005, Gabor Gombas wrote:
> On Fri, Oct 21, 2005 at 02:15:28AM +0100, Darren Salt wrote:
> > I can see potential problems with that last part regarding upstream
> > developers whose software happens to depend on packages for which pkg-config
> > support remains Debian-specific becaus
On Fri, Oct 21, 2005 at 02:15:28AM +0100, Darren Salt wrote:
> I can see potential problems with that last part regarding upstream
> developers whose software happens to depend on packages for which pkg-config
> support remains Debian-specific because upstream doesn't accept the patch.
> It's poss
On Fri, Oct 21, 2005 at 07:15:38PM +0200, Kurt Roeckx wrote:
3D
> Pretty please don't suggest that unless you first fix pkg-config.
> It's always linking in the libraries required for static linking
> even if you don't request it. See for instance bug #254290,
> which was closed, but didn't reall
On Fri, Oct 21, 2005 at 10:24:11PM +0200, Goswin von Brederlow wrote:
> The problem is that pc files are architecture dependent. With
> multiarch there will be
>
> /usr/lib/i486-linux-gnu/glib.pc
> /usr/lib/x86_64-linux-gnu/glib.pc
Well, pkg-config already places .pc files under /usr/lib instead
On Thu, Oct 20, 2005 at 09:16:01PM +0200, Gabor Gombas wrote:
> - Make pkg-config mandatory. pkg-config can already handle the case that
> different libraries are needed for static and shared linking.
> pkg-config also helps the second problem (conflicting -dev packages),
> see below
Did pkg
On Thu, Oct 20, 2005 at 09:16:01PM +0200, Gabor Gombas wrote:
> - Make pkg-config mandatory. pkg-config can already handle the case that
> different libraries are needed for static and shared linking.
> pkg-config also helps the second problem (conflicting -dev packages),
> see below
Pretty
I demand that Gabor Gombas may or may not have written...
[snip]
> So I propose a different solution, which is not perfect, but is better than
> the current situation:
> - -dev packages should only Depend: on other -dev packages neccessary
> for shared linking
> - -dev packages should Recommend
Hi,
(Parts of this topic has been discussed before, but the issues were not
solved, so let's try again).
Today I wanted to install libcurl-openssl-dev, because I wanted to build
an application locally that can utilize libcurl (and for the curious, I
choose libcurl-openssl-dev because the applicat
26 matches
Mail list logo
