Hi,
Le sam. 15 juil. 2023, 17:36, Nicolas Boulenguez a
écrit :
> Julien Puydt
> > - Indeed this is quite fragile; I have two scripts for Coq packages [1]:
> > one to tell me about the deps (I give it which package I have to upgrade
> > and it gives the list of affected packages by pass) and
Julien Puydt
> - Indeed this is quite fragile; I have two scripts for Coq packages [1]:
> one to tell me about the deps (I give it which package I have to upgrade
> and it gives the list of affected packages by pass) and the other to
> generate the migration script (I give it the list of new
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
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:
On Mon, Oct 31, 2005 at 11:15:35PM -0800, Russ Allbery wrote:
I don't consider this to be a good solution. #include krb5.h is part
of the API, and forcing all packages that want to build with Kerberos
to use special compiler flags to find include files
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 assumes
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 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. Using
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 libb, and the
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 of
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 really
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
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 because
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:
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
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-config already
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
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
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
decide
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 request it.
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 should
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 static
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 symbols liba needs
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 you use,
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
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
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
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:
Andrew == Andrew Suffield [EMAIL PROTECTED] writes:
Andrew Recommends and Suggests are not considered when installing
Andrew build-dependencies.
And packages aren't supposed to be built staticly either. Packages
that do build staticly could explicitly Build-Depend on whatever they
On 03 Sep 2002 11:58:10 -0700
Stephen Zander [EMAIL PROTECTED] wrote:
What is the thinking behind always requiring libfoo-dev to depend on
libbar-dev when libfoo depends on libbar? I understand the need when
/usr/include/foo.h contains
#include bar.h
So that libbar-dev can conflict
What is the thinking behind always requiring libfoo-dev to depend on
libbar-dev when libfoo depends on libbar? I understand the need when
/usr/include/foo.h contains
#include bar.h
but if libfoo opaquely wraps libbar, why have libfoo-dev depend on
libbar-dev?
--
Stephen
Farcical aquatic
On Tue, Sep 03, 2002 at 11:58:10 -0700, Stephen Zander wrote:
but if libfoo opaquely wraps libbar, why have libfoo-dev depend on
libbar-dev?
How opaque is that opaque when considering the case of linking against a
library statically?
Ray
--
The problem with the global village is all the
Stephen Zander [EMAIL PROTECTED] writes:
What is the thinking behind always requiring libfoo-dev to depend on
libbar-dev when libfoo depends on libbar? I understand the need when
/usr/include/foo.h contains
#include bar.h
but if libfoo opaquely wraps libbar, why have libfoo-dev depend
Ray == J H M Dassen J.H.M. writes:
Ray How opaque is that opaque when considering the case of
Ray linking against a library statically?
That need might reasonably be met with a Recommends: or Suggests:
--
Stephen
To Republicans, limited government means not assisting people they
would
On Tue, Sep 03, 2002 at 01:57:33PM -0700, Stephen Zander wrote:
Ray == J H M Dassen J.H.M. writes:
Ray How opaque is that opaque when considering the case of
Ray linking against a library statically?
That need might reasonably be met with a Recommends: or Suggests:
Recommends and
On Tue, 03 Sep 2002, Goswin Brederlow wrote:
Stephen Zander [EMAIL PROTECTED] writes:
What is the thinking behind always requiring libfoo-dev to depend on
libbar-dev when libfoo depends on libbar? I understand the need when
The lack of symbol versioning, about 90% of the time.
but if
I wrote a longer response to this but then thought about what you
wrote a bit more and deleted it.
Henrique == Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
Henrique The lack of symbol versioning, about 90% of the time.
Then why not mandate symbol versioning instead; that would be
On Tue, 03 Sep 2002, Stephen Zander wrote:
I wrote a longer response to this but then thought about what you
wrote a bit more and deleted it.
Henrique == Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
Henrique The lack of symbol versioning, about 90% of the time.
Then why not
38 matches
Mail list logo
