On Thu, Jun 30, 2005 at 11:01:17AM -0300, Gustavo Noronha Silva wrote:
> I have a question about this requirement:
>
> Packages must not install programs in the default PATH with
> different functionality with the same file name, even if they
> Conflict:.
>
> Totem and Glade, fo
Em Ter, 2005-06-28 às 00:43 +0200, Andreas Barth escreveu:
> Hi, All,
Hey,
> As always, the full canoncial list of the RC policy for etch is available
> at http://release.debian.org/etch_rc_policy.txt .
I feel there's too much redundancy there when taking debian policy into
account, is that redu
Russ Allbery <[EMAIL PROTECTED]> writes:
>> If the ABI changes but not the SONAME then the only sane thing to do is
>> to encode the ABI in the package name, e.g. libstc++-6c1002. Just like
>> for any other lib doing the upcoming c++ abi transition.
>
> We agree on this.
So just to make sure we'r
Russ Allbery <[EMAIL PROTECTED]> writes:
> I think you're still too caught up on libstdc++, the library. The library
> is not the C++ ABI, just like how libgcc is not used by all C programs.
> The C++ ABI involves things like how classes are laid out and how function
> names are mangled.
So what
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:
>> I think you're confusing the C++ ABI with the SONAME of libstdc++.
>> They're not necessarily the same thing, although right now they tend to
>> change at the same time. Having the SONAME of libstdc++ c
Russ Allbery <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>
>> [EMAIL PROTECTED]:~% apt-cache show mozilla-dev
>> Package: mozilla-dev
>> Architecture: amd64
>> Source: mozilla
>> Version: 2:1.7.8-1
>> Depends: mozilla-browser (= 2:1.7.8-1), libnspr-dev (= 2:1.7.8
Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED]:~% apt-cache show mozilla-dev
> Package: mozilla-dev
> Architecture: amd64
> Source: mozilla
> Version: 2:1.7.8-1
> Depends: mozilla-browser (= 2:1.7.8-1), libnspr-dev (= 2:1.7.8-1), libxt-dev,
> libc6 (>= 2.3.2.ds1-21), libgcc1
Matthias Klose <[EMAIL PROTECTED]> writes:
> How can you tell, for which C++ ABI packages like mozilla-dev and
> festival-dev are built? IMO that is the technical reason you are
> asking for. It doesn't matter if an application or a library is linked
> to libstdc++. Remember that C++ ABI != libstd
* Andreas Barth:
>> Wouldn't it be sufficient to defer to generic policy on this one? PIC
>> library/DSO support is mostly a C/C++-specific domain, and not
>> everything that Debian ships is written in C/C++ or some scripting
>> language.
>
> Do we have such a policy available?
Policy section 10
* Florian Weimer ([EMAIL PROTECTED]) [050609 15:16]:
> * Andreas Barth:
> > About:
> > Shared libraries must be compiled with -fPIC, and normally static
> > libraries must not be. If you need to provide static libraries
> > compiled with -fPIC, call it "_pic.a".
> >
> > There was some
* Andreas Barth:
> One addition I would like very much to see is:
> A library that is included in a package in Debian must be linked to
> dynamically; for static-only executables like sash also static linking
> to that other library package is accepted. Importing and using the
> source code of
On Thu, 9 Jun 2005, Jeroen van Wolffelaar wrote:
> On Thu, Jun 09, 2005 at 12:35:17AM +0200, Matthias Klose wrote:
> > one more thing: C++ dependencies are currently "hidden" within
> > build-essential. Currently you cannot see this dependency from the
> > outside, if the code is not dynamically
On Thu, Jun 09, 2005 at 12:09:26AM +0200, Andreas Barth wrote:
> Rationale:
> Some libraries are provided multiple in Debian, IIRC e.g. libz. That is
> bad from general QA (as usually this is just an old version, and normale
> bug fixes don't go in), and especially bad if there is a security updat
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [050609 00:38]:
> Andreas Barth <[EMAIL PROTECTED]> writes:
> > One addition I would like very much to see is:
> > A library that is included in a package in Debian must be linked to
> > dynamically; for static-only executables like sash also static lin
Thomas Bushnell BSG writes:
> Matthias Klose <[EMAIL PROTECTED]> writes:
>
> > one more thing: C++ dependencies are currently "hidden" within
> > build-essential. Currently you cannot see this dependency from the
> > outside, if the code is not dynamically linked to libstdc++ (or
> > doesn't use
Joerg Jaspert <[EMAIL PROTECTED]> writes:
> #311724
>
> cdbs is an example for this madness (B-D) here, maybe others do it too.
Oh, blech. Yes, I agree this should be prohibited. Never occurred to
me to do something like that.
I think a suitable substitute would be, instead of generating new
B
On 10315 March 1977, Thomas Bushnell wrote:
>> Rationale:
>> Well, the contents of both are decisions of the maintainer. It is IMHO
>> very bad if a package starts to change build dependencies during a NMU
>> or an security upload, and even worse if the maintainer is "adjusted" in
>> the binary pa
Matthias Klose <[EMAIL PROTECTED]> writes:
> How can you tell, for which C++ ABI packages like mozilla-dev and
> festival-dev are built? IMO that is the technical reason you are
> asking for. It doesn't matter if an application or a library is linked
> to libstdc++. Remember that C++ ABI != libstd
On Thu, Jun 09, 2005 at 12:35:17AM +0200, Matthias Klose wrote:
> one more thing: C++ dependencies are currently "hidden" within
> build-essential. Currently you cannot see this dependency from the
> outside, if the code is not dynamically linked to libstdc++ (or
> doesn't use libstdc++ at all).
Matthias Klose <[EMAIL PROTECTED]> writes:
> one more thing: C++ dependencies are currently "hidden" within
> build-essential. Currently you cannot see this dependency from the
> outside, if the code is not dynamically linked to libstdc++ (or
> doesn't use libstdc++ at all). I'm proposing to req
Andreas Barth writes:
> One addition I would like very much to see is:
> A library that is included in a package in Debian must be linked to
> dynamically; for static-only executables like sash also static linking
> to that other library package is accepted. Importing and using the
> source cod
Andreas Barth <[EMAIL PROTECTED]> writes:
> One addition I would like very much to see is:
> A library that is included in a package in Debian must be linked to
> dynamically; for static-only executables like sash also static linking
> to that other library package is accepted. Importing and us
Hi,
I looked through our release policy. There are some changes I think we
should or need to make.
One addition I would like very much to see is:
A library that is included in a package in Debian must be linked to
dynamically; for static-only executables like sash also static linking
to that
23 matches
Mail list logo
