Re: X Strike Force SVN commit: rev 69 - branches/4.3.0/sid/debian
On Thu, 2003-05-29 at 04:59, Matthias Klose wrote: As the g++ package, which makes 3.3 the default, entered testing today, I files a report to build-essential to do this change, maybe this needs to be reflected in policy as well. Does anyone have any objections to this change? (I doubt it, but it's my policy to consult -devel about changes to build-essential)
Re: X Strike Force SVN commit: rev 69 - branches/4.3.0/sid/debian
On Mon, May 26, 2003 at 10:22:41PM +0200, Matthias Klose wrote:
Branden Robinson writes:
Questions for debian-{x,devel}:
1) Should libstdc++-dev dependencies be made artificially strict in
packages destined for sid so that it's harder for packages built
against, say, libstdc++3 to accidentally sneak in and start regressing
the C++ ABI transition progress?
A dependency on the libstdc++-dev package is not (yet) needed, as
every new major version of gcc comes with a new libstdc++XXX-dev
package. Maybe it's better to depend on g++ (= 3:3.3-1) or a specific
g++ version if yoou need it. I'll file a report on build-essential to
tighten this dependency.
I have to admit I'm not completely clear on what you mean here.
Why should a -dev package for a C++ library declare a versioned
dependency on the compiler? Why isn't it sufficient to declare a
dependency, even a specific one, on the standard C++ library?
Or are you saying that depending on g++ (= 3:3.3-1) is the best way to
prevent people from accidentally regressing the C++ ABI transition
progress?
If so, shouldn't we make that Policy?
--
G. Branden Robinson| Communism is just one step on the
Debian GNU/Linux | long road from capitalism to
[EMAIL PROTECTED] | capitalism.
http://people.debian.org/~branden/ | -- Russian saying
pgpZS3tGSbeKM.pgp
Description: PGP signature
Re: X Strike Force SVN commit: rev 69 - branches/4.3.0/sid/debian
Branden Robinson writes:
On Mon, May 26, 2003 at 10:22:41PM +0200, Matthias Klose wrote:
Branden Robinson writes:
Questions for debian-{x,devel}:
1) Should libstdc++-dev dependencies be made artificially strict in
packages destined for sid so that it's harder for packages built
against, say, libstdc++3 to accidentally sneak in and start regressing
the C++ ABI transition progress?
A dependency on the libstdc++-dev package is not (yet) needed, as
every new major version of gcc comes with a new libstdc++XXX-dev
package. Maybe it's better to depend on g++ (= 3:3.3-1) or a specific
g++ version if yoou need it. I'll file a report on build-essential to
tighten this dependency.
I have to admit I'm not completely clear on what you mean here.
Why should a -dev package for a C++ library declare a versioned
dependency on the compiler? Why isn't it sufficient to declare a
dependency, even a specific one, on the standard C++ library?
g++-3.2 has /usr/include/c++/3.2 in the include path, g++-3.3
/usr/include/c++/3.3. Declaring a dependency on libstdc++5-dev
(gcc-3.2 based) and building with g++ (= 3:3.3) doesn't use
libstdc++5-dev, but libstdc++5-3.3-dev.
Or are you saying that depending on g++ (= 3:3.3-1) is the best way to
prevent people from accidentally regressing the C++ ABI transition
progress?
If so, shouldn't we make that Policy?
As the g++ package, which makes 3.3 the default, entered testing
today, I files a report to build-essential to do this change, maybe
this needs to be reflected in policy as well.
Matthias
Re: X Strike Force SVN commit: rev 69 - branches/4.3.0/sid/debian
On Thu, May 29, 2003 at 10:59:01AM +0200, Matthias Klose wrote:
Branden Robinson writes:
On Mon, May 26, 2003 at 10:22:41PM +0200, Matthias Klose wrote:
Branden Robinson writes:
Questions for debian-{x,devel}:
1) Should libstdc++-dev dependencies be made artificially strict in
packages destined for sid so that it's harder for packages built
against, say, libstdc++3 to accidentally sneak in and start regressing
the C++ ABI transition progress?
A dependency on the libstdc++-dev package is not (yet) needed, as
every new major version of gcc comes with a new libstdc++XXX-dev
package. Maybe it's better to depend on g++ (= 3:3.3-1) or a specific
g++ version if yoou need it. I'll file a report on build-essential to
tighten this dependency.
I have to admit I'm not completely clear on what you mean here.
Why should a -dev package for a C++ library declare a versioned
dependency on the compiler? Why isn't it sufficient to declare a
dependency, even a specific one, on the standard C++ library?
g++-3.2 has /usr/include/c++/3.2 in the include path, g++-3.3
/usr/include/c++/3.3. Declaring a dependency on libstdc++5-dev
(gcc-3.2 based) and building with g++ (= 3:3.3) doesn't use
libstdc++5-dev, but libstdc++5-3.3-dev.
Well, uh, so what? If G++ 3.2 and 3.3 have compatible ABIs, and the
standard C++ libraries are compatible at the source level, does the
above really matter?
Or are you saying that depending on g++ (= 3:3.3-1) is the best way to
prevent people from accidentally regressing the C++ ABI transition
progress?
If so, shouldn't we make that Policy?
As the g++ package, which makes 3.3 the default, entered testing
today, I files a report to build-essential to do this change, maybe
this needs to be reflected in policy as well.
For purposes of Policy I'm interesting in nailing down what it means for
a -dev package to depend on something, what those dependencies should
generally be, and why.
--
G. Branden Robinson|I have a truly elegant proof of the
Debian GNU/Linux |above, but it is too long to fit
[EMAIL PROTECTED] |into this .signature file.
http://people.debian.org/~branden/ |
pgpCkX0HgeE5c.pgp
Description: PGP signature
Re: X Strike Force SVN commit: rev 69 - branches/4.3.0/sid/debian
On Mon, May 26, 2003 at 08:48:23AM -0500, X Strike Force SVN Admin wrote:
Author: daniel
Date: 2003-05-26 08:48:12 -0500 (Mon, 26 May 2003)
New Revision: 69
Modified:
branches/4.3.0/sid/debian/control
Log:
Changed references to libstdc++5-dev to libstdc++5-dev | libstdc++-dev,
allowing
libstdc++5-3.3-dev to satisfy the dependency, and thus gcc3.2 to be deleted.
(closes: #194136)
This is a changelog-worthy commit, so please commit a change to the
changelog as part of the same changeset in the future.
More importantly, when this bug was first reported, several old timers
and I had a long conversation on OPN's #debian-devel channel about what
dependencies of -dev packages really mean. There are at least three
possibilities, and no Policy on which is controlling:
1) just what the package actually needs to install successfully (which
is usually nothing);
2) just packages containing header files referenced by the headers in
the package;
3) 2), plus -dev packages of any libraries that would necessarily be
linked against when people compile something linked with an object in
the -dev.
Questions for debian-{x,devel}:
1) Should libstdc++-dev dependencies be made artificially strict in
packages destined for sid so that it's harder for packages built
against, say, libstdc++3 to accidentally sneak in and start regressing
the C++ ABI transition progress?
2) Is libstdc++5-3.3 ABI-compatible with libstdc+5? Does the former
have any symbols that the latter lacks?
--
G. Branden Robinson| There is no gravity in space.
Debian GNU/Linux | Then how could astronauts walk
[EMAIL PROTECTED] | around on the Moon?
http://people.debian.org/~branden/ | Because they wore heavy boots.
pgp12OV0AWKaI.pgp
Description: PGP signature
Re: X Strike Force SVN commit: rev 69 - branches/4.3.0/sid/debian
Branden Robinson writes:
Questions for debian-{x,devel}:
1) Should libstdc++-dev dependencies be made artificially strict in
packages destined for sid so that it's harder for packages built
against, say, libstdc++3 to accidentally sneak in and start regressing
the C++ ABI transition progress?
A dependency on the libstdc++-dev package is not (yet) needed, as
every new major version of gcc comes with a new libstdc++XXX-dev
package. Maybe it's better to depend on g++ (= 3:3.3-1) or a specific
g++ version if yoou need it. I'll file a report on build-essential to
tighten this dependency.
2) Is libstdc++5-3.3 ABI-compatible with libstdc+5? Does the former
have any symbols that the latter lacks?
Yes. No (modulo bugs). You can check this by comparing
/usr/share/doc/libstdc++5-dev/README.libstdc++5-baseline
and
/usr/share/doc/libstdc++5-3.3-dev/README.libstdc++5-3.3-baseline
Matthias
Re: X Strike Force SVN commit: rev 69 - branches/4.3.0/sid/debian
On Mon, May 26, 2003 at 01:54:57PM -0500, Branden Robinson wrote: 1) Should libstdc++-dev dependencies be made artificially strict in packages destined for sid so that it's harder for packages built against, say, libstdc++3 to accidentally sneak in and start regressing the C++ ABI transition progress? Well, this isn't a problem for buildds, because I made libstdc++5-dev the preference. 2) Is libstdc++5-3.3 ABI-compatible with libstdc+5? Does the former have any symbols that the latter lacks? I *believe* it's completely ABI-compatible, but I could be wrong. -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgphpDyejfWsS.pgp Description: PGP signature
Re: X Strike Force SVN commit: rev 69 - branches/4.3.0/sid/debian
Daniel Stone writes: On Mon, May 26, 2003 at 01:54:57PM -0500, Branden Robinson wrote: 1) Should libstdc++-dev dependencies be made artificially strict in packages destined for sid so that it's harder for packages built against, say, libstdc++3 to accidentally sneak in and start regressing the C++ ABI transition progress? Well, this isn't a problem for buildds, because I made libstdc++5-dev the preference. for this to work, you have to explicitely build using g++-3.2 (build dependency and setting of CC/CXX). using g++ means building with libstdc++5-3.3-dev.
Re: X Strike Force SVN commit: rev 69 - branches/4.3.0/sid/debian
On Monday, May 26, 2003, at 02:54 PM, Branden Robinson wrote: what dependencies of -dev packages really mean. There are at least three possibilities, and no Policy on which is controlling: 1) just what the package actually needs to install successfully (which is usually nothing); 2) just packages containing header files referenced by the headers in the package; 3) 2), plus -dev packages of any libraries that would necessarily be linked against when people compile something linked with an object in the -dev. I'm a very strong believer that any header file which requires another header file should include it. I think that most Debian developers are with me on this issue; the old-style make the client include what I need headers are losing favour, I think. So, given this idea of making header files include what they need, it seems pretty natural to extend that idea to -dev packages. Thus, -dev packages should depend on what they need to work; this includes all header files they include. I imagine a dpkg-shlibdeps workalike could be created for this purpose if it became an issue. w.r.t point 3, I think it's pretty natural to extend earlier ideas to symbols needed at link time. In most cases this will probably have a fairly large intersection with the set of packages depended upon for their headers. I think it makes sense to Depend upon -dev packages which are required (most of the time?) when building a program using the library in question. The idea is to make -dev packages as useful as possible, so a person doesn't get a rude shock when they have to install a whole whack of other packages just to get their GLU-using programs to compile.
