Steve == Steve Greenland [EMAIL PROTECTED] writes:
fact 3: libtool library libtool tries to implement a wrapper
around shared library and static library, so that both of them
can be uniformly processed, and allows specifying just: libtool
cc -lnewt a.c
Steve Why is this
On Thu, Jul 28, 2005 at 02:18:29PM -0400, Jay Berkenbilt wrote:
FWIW, detecting a fixed libtool would be rather difficult, since it's the
libtool used by the depending application which does the recursion and
therefore needs to be fixed.
I was thinking we'd be able to tell from the .la
On 29-Jul-05, 08:50 (CDT), GOMBAS Gabor [EMAIL PROTECTED] wrote:
On Thu, Jul 28, 2005 at 08:38:17AM -0500, Steve Greenland wrote:
Exercise: let's say I have an application that uses GSSAPI, and has to
be able to be built statically. Requirements:
- It should build with Heimdal's libgssapi
On Thu, Jul 28, 2005 at 08:38:17AM -0500, Steve Greenland wrote:
Why is this better? I have to change my perfectly normal, standard Unix
link command to use something that completely hides the actual link
command and makes debugging problems nearly impossible?
Exercise: let's say I have an
On Thu, Jul 28, 2005 at 07:05:34AM -0400, Stephen Frost wrote:
We've had that discussion before. Last I recall there wasn't really a
huge fight to keep them.
Well, Debian developers do not really need them. But there are people
who do not develop Debian but develop other software _using_
On Thu, Jul 28, 2005 at 08:57:29AM -0400, Stephen Frost wrote:
I'd think we could come up with a way to detect the version of libtool
in use, somehow. :)
LTMAIN_SH_PATH=`autoconf --trace='AC_CONFIG_AUX_DIR:$1'`
LTMAIN_SH_PATH=${LTMAIN_SH_PATH:-.}
grep ^VERSION $LTMAIN_SH_PATH/ltmain.sh | cut
GOMBAS Gabor [EMAIL PROTECTED] wrote:
On Thu, Jul 28, 2005 at 08:57:29AM -0400, Stephen Frost wrote:
I'd think we could come up with a way to detect the version of libtool
in use, somehow. :)
LTMAIN_SH_PATH=`autoconf --trace='AC_CONFIG_AUX_DIR:$1'`
LTMAIN_SH_PATH=${LTMAIN_SH_PATH:-.}
grep
On Fri, Jul 29, 2005 at 12:06:38PM -0400, Jay Berkenbilt wrote:
This is nice, but I think it's not really very autoconfish [tm] in
spirit.
It is not meant to be autoconfish. It is meant to be run _before_
configure, so you can decide if you have to re-libtoolize the package or
not.
Also,
Hi,
- Kill the .la files and .a files. Drop support for static linking. Not
something that should be done lightly and without prior project-wide
discussion.
- Leave the .la files in place; -dev packages need to depend on -dev
packages corresponding to those runtime dependencies
* Steve Langasek ([EMAIL PROTECTED]) wrote:
On Wed, Jul 27, 2005 at 08:57:51PM -0400, Stephen Frost wrote:
* Steve Langasek ([EMAIL PROTECTED]) wrote:
On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
libtool is broken in this regard and needs to be fixed to survive
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
- Option 4 (requires volunteers): fix libtool
Blankly stating that libtool needs to be 'fixed'
because it is 'broken' is not very helpful.
Would you care to explain what needs to be fixed and why
it is broken? Good working examples would be
Steve Langasek [EMAIL PROTECTED] wrote:
- Leave the .la files in place; -dev packages need to depend on -dev
packages corresponding to those runtime dependencies that are also built
using libtool. This is the status quo.
If we do this (which I think we should for now), I would suggest
On Thu, Jul 28, 2005 at 08:29:52AM -0400, Jay Berkenbilt wrote:
Steve Langasek [EMAIL PROTECTED] wrote:
- Leave the .la files in place; -dev packages need to depend on -dev
packages corresponding to those runtime dependencies that are also built
using libtool. This is the status quo.
* Steve Langasek ([EMAIL PROTECTED]) wrote:
It doesn't exist; I think it's a great idea. Perhaps a tool named
dh_libtool, which populates a substvar named ${libtool:Depends}?
This sounds reasonable to me; I appriciate that it's a libtool-specific
thing and not a blanket policy. :)
FWIW,
On 28-Jul-05, 03:02 (CDT), Junichi Uekawa [EMAIL PROTECTED] wrote:
fact 1: shared library
gcc -lnewt a.c
Right. No problem.
fact 2: static library
gcc -lslang -lnewt a.c
Right, Just like it's always been on Unix systems.
fact 3: libtool library
libtool tries to implement a
Steve Langasek [EMAIL PROTECTED] wrote:
It doesn't exist; I think it's a great idea. Perhaps a tool named
dh_libtool, which populates a substvar named ${libtool:Depends}?
Sounds good to me.
I'm going to be leaving my current job in a few weeks and taking
several weeks off between jobs. I'll
Hi,
- Don't ship .la files in the -dev package; don't depend on any other -dev
packages except those whose headers you need. This gives optimal results
for shared linking by pruning all unnecessary build-dependencies and
dependencies; but it also screws over anyone trying to do
On Fri, Jul 29, 2005 at 07:06:34AM +0900, Junichi Uekawa wrote:
- Don't ship .la files in the -dev package; don't depend on any other -dev
packages except those whose headers you need. This gives optimal
results
for shared linking by pruning all unnecessary build-dependencies and
Steve Langasek [EMAIL PROTECTED] writes:
I think static libs have outlived their usefulness in Debian for the
most part; but using this to justify creating whole *new* packages for
static linking would just be insane. The dependencies of -dev packages
are just not that big a deal to warrant
Hi,
Since I've started up this thread, I'd like to summarize what was
discussed in this thread.
1. Conclusion:
For the initial question of
'How does one decide which -dev package accompanies
runtime library package'
There is no answer, and we have not reached the consensus.
2. Methods
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
1. Conclusion:
For the initial question of
'How does one decide which -dev package accompanies
runtime library package'
There is no answer, and we have not reached the consensus.
It would be possible to put forth a proposal to deal with
On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
4. -dev packages should depend on other -dev packages?
Yes.
Whoah, whoah, whoah. This is just blatently false. There *certainly*
wasn't a consensus that -dev packages should regularly depend on -dev
pacakges. There's a
* Steve Langasek ([EMAIL PROTECTED]) wrote:
On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
libtool is broken in this regard and needs to be fixed to survive
missing files.
Then fix it instead of giving people bad advice.
Do you actually have anything beyond libtool breaks
On Wed, Jul 27, 2005 at 08:57:51PM -0400, Stephen Frost wrote:
* Steve Langasek ([EMAIL PROTECTED]) wrote:
On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
libtool is broken in this regard and needs to be fixed to survive
missing files.
Then fix it instead of giving
On Wednesday 27 July 2005 10:10 pm, Steve Langasek wrote:
But ok, yes, that is an option; let's spell the options out completely:
- Don't ship .la files in the -dev package; don't depend on any other
-dev packages except those whose headers you need. This gives optimal
results for shared
On Wed, Jul 27, 2005 at 10:16:54PM -0400, Josh Metzler wrote:
On Wednesday 27 July 2005 10:10 pm, Steve Langasek wrote:
But ok, yes, that is an option; let's spell the options out completely:
- Don't ship .la files in the -dev package; don't depend on any other
-dev packages except those
Junichi Uekawa [EMAIL PROTECTED] wrote:
2. The information of -dev packages depending on other -dev packages
cannot be automatically determined currently;
it should be possible to obtain a minimal list by analyzing the
NEEDED field of the objdump output.
Errr, -dev packages
also sprach Junichi Uekawa [EMAIL PROTECTED] [2005.07.14.1416 +0300]:
libfoobar-2.1-0 will have
libfoobar-2.1-0-dev.
Please distinguish between API and ABI!
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft [EMAIL PROTECTED]
: :' :proud
Hi,
BTW, having Build-Depends: libfoo-dev in
a library's build-deps, will allow the developer
to overlook a soname change in depending shared library.
Which is a bad idea in the QA standpoint.
Yes and no.
The programer can overlook the soname change for the source. The API
hasn't
Hi,
Thanks for your input.
Having a solid naming scheme will allow me to
ldd /usr/lib/libwhatever.so to track down its
shared library dependency, and appending -dev
to individual package to create the list of
requisite -dev packages.
If this is actually necessary for
Hi,
Having a solid naming scheme will allow me to
ldd /usr/lib/libwhatever.so to track down its
shared library dependency, and appending -dev
to individual package to create the list of
requisite -dev packages.
With the current scheme it is:
ldd /usr/lib/libwhatever.so to
On Fri, Jul 15, 2005 at 09:36:47AM +0300, martin f krafft wrote:
also sprach Junichi Uekawa [EMAIL PROTECTED] [2005.07.14.1416 +0300]:
libfoobar-2.1-0 will have
libfoobar-2.1-0-dev.
Please distinguish between API and ABI!
True. Indeed the proposed policy is already followed in case of
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
BTW, having Build-Depends: libfoo-dev in
a library's build-deps, will allow the developer
to overlook a soname change in depending shared library.
Which is a bad idea in the QA standpoint.
Yes and no.
The programer can overlook the
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
If this is actually necessary for libtool-using packages, then write
something which goes through all of the .la files and does this, since
that's what libtool wants to do.
and
Errr, you still havn't said what problem you're trying to solve
* Francesco P. Lovergine ([EMAIL PROTECTED]) wrote:
On Fri, Jul 15, 2005 at 09:36:47AM +0300, martin f krafft wrote:
also sprach Junichi Uekawa [EMAIL PROTECTED] [2005.07.14.1416 +0300]:
libfoobar-2.1-0 will have
libfoobar-2.1-0-dev.
Please distinguish between API and ABI!
Junichi Uekawa [EMAIL PROTECTED] writes:
Hi,
BTW, having Build-Depends: libfoo-dev in
a library's build-deps, will allow the developer
to overlook a soname change in depending shared library.
Which is a bad idea in the QA standpoint.
Yes and no.
The programer can overlook the
Junichi Uekawa [EMAIL PROTECTED] writes:
Hi,
Having a solid naming scheme will allow me to
ldd /usr/lib/libwhatever.so to track down its
shared library dependency, and appending -dev
to individual package to create the list of
requisite -dev packages.
You could also suggest a
Hi,
Thanks for your time and feedback. I appreciate it very much.
You could also suggest a policy for libs to have a libfoo.devname file
similar to the libfoo.shlibs file but naming the needed -dev
packages. If that is a good idea or not you have to think about. Just
a wild idea.
Yes,
On Fri, Jul 15, 2005 at 10:44:04PM +0900, Junichi Uekawa wrote:
Stephen's points are valid and quite useful
considering an upstream developer's point of view,
but for random user joe who is trying to find a development
package, one of the following may help him find the right package
1.
Stephen's points are valid and quite useful
considering an upstream developer's point of view,
but for random user joe who is trying to find a development
package, one of the following may help him find the right package
Joe user should do:
apt-cache search libNAME dev
(or use synaptic,
On Fri, Jul 15, 2005 at 05:18:23PM +0900, Junichi Uekawa wrote:
BTW, having Build-Depends: libfoo-dev in
a library's build-deps, will allow the developer
to overlook a soname change in depending shared library.
Which is a bad idea in the QA standpoint.
Yes and no.
The programer
On Fri, Jul 15, 2005 at 05:30:44PM +0900, Junichi Uekawa wrote:
Having a solid naming scheme will allow me to
ldd /usr/lib/libwhatever.so to track down its
shared library dependency, and appending -dev
to individual package to create the list of
requisite -dev packages.
If
On 7/15/05, Steve Langasek [EMAIL PROTECTED] wrote:
On Fri, Jul 15, 2005 at 05:30:44PM +0900, Junichi Uekawa wrote:
An alternate solution is to have a database for that kind of thing,
but I forsee that it requires effort to maintain and keep up-to-date.
Like the database I just queried
[I am stopping the cross-posting to -release, as -release is no
discussion list]
On 2005-07-14 Junichi Uekawa [EMAIL PROTECTED] wrote:
I'd like to propose, for new -dev packages, to
name -dev packages after their runtime library counterparts.
If the library package is named lib$NAME,
call
Hi,
I'd like to propose, for new -dev packages, to
name -dev packages after their runtime library counterparts.
If the library package is named lib$NAME,
call the -dev package lib$NAME-dev.
For example,
libxxx0 will have
libxxx0-dev.
libfoobar-2.1-0 will have
libfoobar-2.1-0-dev.
This
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
I'd like to propose, for new -dev packages, to
name -dev packages after their runtime library counterparts.
Uh, no? The -dev packages have no need to match to a specific runtime
library and this just creates unnecessary work.
This allows
On Thu, 2005-07-14 at 20:16 +0900, Junichi Uekawa wrote:
I'd like to propose, for new -dev packages, to
name -dev packages after their runtime library counterparts.
I personally found it very handy that the dev packages automatically
selects the most recent API compatible version. Why do you
Hi,
I'd like to propose, for new -dev packages, to
name -dev packages after their runtime library counterparts.
If the library package is named lib$NAME,
call the -dev package lib$NAME-dev.
[...]
Hej,
The obvious downside of this is that the name of dev-package will change
Hi,
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
I'd like to propose, for new -dev packages, to
name -dev packages after their runtime library counterparts.
Uh, no? The -dev packages have no need to match to a specific runtime
library and this just creates unnecessary work.
Well, I
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
There may be other showstoppers.
What does doing this solve? What does it even help with?
I would really like this 10-year old non-regulation to
go to a concensus (it is indeed rather embarassing we don't
agree on a good solution after 10
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
I'd like to propose, for new -dev packages, to
name -dev packages after their runtime library counterparts.
Uh, no? The -dev packages have no need to match to a specific runtime
library and
Junichi Uekawa [EMAIL PROTECTED] writes:
Hi,
I'd like to propose, for new -dev packages, to
name -dev packages after their runtime library counterparts.
If the library package is named lib$NAME,
call the -dev package lib$NAME-dev.
[...]
Hej,
The obvious downside of this is
[once more, doesn't belong on -release...]
On Thu, Jul 14, 2005 at 12:11:21PM -0400, Stephen Frost wrote:
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
I'd like to propose, for new -dev packages, to
name -dev packages after their runtime
Hi,
There may be other showstoppers.
What does doing this solve? What does it even help with?
Hmmm... we are talking about naming
Debian development shareed library package names based on
Debian runtime shared library package names.
I would really like this 10-year old
Hi,
I'd like to propose, for new -dev packages, to
name -dev packages after their runtime library counterparts.
I personally found it very handy that the dev packages automatically
selects the most recent API compatible version. Why do you want this
switch by the way? You did not name
On Thursday 14 July 2005 17:14, Junichi Uekawa wrote:
The current recommendation I'm trying to give is:
Package: libXXX-dev
Conflicts: libXXX-dev
Provides: libXXX-dev
Thus, it won't contradict with your requirement to
be able to just build-depend on libXXX-dev.
I may be wrong, but I
Hi,
You can (and it is often done) extend an api to include more
functionality without breaking the existing api. Any program using one
of the new functions must use a versioned depend on the libfoo-dev
package introducing the function.
The API can (and will) even stay compatibly across
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
There may be other showstoppers.
What does doing this solve? What does it even help with?
Hmmm... we are talking about naming
Debian development shareed library package names based on
Debian runtime shared library package names.
Errr, you
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
BTW, having Build-Depends: libfoo-dev in
a library's build-deps, will allow the developer
to overlook a soname change in depending shared library.
Which is a bad idea in the QA standpoint.
Uh, no it isn't. SONAME changes are fine, the package has
Hi,
2. The information of -dev packages depending on other -dev packages
cannot be automatically determined currently;
it should be possible to obtain a minimal list by analyzing the
NEEDED field of the objdump output.
Errr, -dev packages generally don't (and shouldn't) depend on
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
The current recommendation I'm trying to give is:
Package: libXXX-dev
Conflicts: libXXX-dev
Provides: libXXX-dev
Thus, it won't contradict with your requirement to
be able to just build-depend on libXXX-dev.
Uhh, then it doesn't fix your
#include hallo.h
* Will Newton [Thu, Jul 14 2005, 05:36:05PM]:
Thus, it won't contradict with your requirement to
be able to just build-depend on libXXX-dev.
I may be wrong, but I thought it was incorrect to build-dep only on a pure
virtual package? e.g.:
Build-Depend: xlibmesa-gl-dev
Will Newton [EMAIL PROTECTED] writes:
On Thursday 14 July 2005 17:14, Junichi Uekawa wrote:
The current recommendation I'm trying to give is:
Package: libXXX-dev
Conflicts: libXXX-dev
Provides: libXXX-dev
Thus, it won't contradict with your requirement to
be able to just
Junichi Uekawa [EMAIL PROTECTED] writes:
Having a solid naming scheme will allow me to
ldd /usr/lib/libwhatever.so to track down its
shared library dependency, and appending -dev
to individual package to create the list of
requisite -dev packages.
With the current scheme it is:
ldd
Junichi Uekawa [EMAIL PROTECTED] writes:
BTW, having Build-Depends: libfoo-dev in
a library's build-deps, will allow the developer
to overlook a soname change in depending shared library.
Which is a bad idea in the QA standpoint.
Yes and no.
The programer can overlook the soname change for
65 matches
Mail list logo
