At Thu, 14 Apr 2005 10:24:01 +0200,
Matthias Klose wrote:
> - The rules outlined above should make the autobuilders build your
> packages with GCC 4.0.
>
> TODO: check for other incompatibilities for non-release
> architectures,
>
> * i.e. sparc and hppa. I.e.: hppa libgcc1 (SJLJ) -> libg
On Tue, Apr 26, 2005 at 01:31:46AM -0700, Steve Langasek wrote:
> On Tue, Apr 26, 2005 at 09:15:09AM +0200, Matthias Klose wrote:
> > A proposal for a simplification, which reduces/avoids the renaming of
> > the KDE packages. All KDE packages depend directly or indirectly on
> > libqt3, so it is en
On Tue, Apr 26, 2005 at 11:52:25AM +0200, Achim Bohnet wrote:
> On Tuesday 26 April 2005 10:31, Steve Langasek wrote:
> > On Tue, Apr 26, 2005 at 09:15:09AM +0200, Matthias Klose wrote:
> > > A proposal for a simplification, which reduces/avoids the renaming of
> > > the KDE packages. All KDE packa
On Tuesday 26 April 2005 10:31, Steve Langasek wrote:
> On Tue, Apr 26, 2005 at 09:15:09AM +0200, Matthias Klose wrote:
> > A proposal for a simplification, which reduces/avoids the renaming of
> > the KDE packages. All KDE packages depend directly or indirectly on
> > libqt3, so it is enough to r
Steve Langasek writes:
> On Tue, Apr 26, 2005 at 09:15:09AM +0200, Matthias Klose wrote:
> > A proposal for a simplification, which reduces/avoids the renaming of
> > the KDE packages. All KDE packages depend directly or indirectly on
> > libqt3, so it is enough to rename the packages libqt3c102 to
On Tue, Apr 26, 2005 at 09:15:09AM +0200, Matthias Klose wrote:
> A proposal for a simplification, which reduces/avoids the renaming of
> the KDE packages. All KDE packages depend directly or indirectly on
> libqt3, so it is enough to rename the packages libqt3c102 to libqt3
> and libqt3c102-mt to
A proposal for a simplification, which reduces/avoids the renaming of
the KDE packages. All KDE packages depend directly or indirectly on
libqt3, so it is enough to rename the packages libqt3c102 to libqt3
and libqt3c102-mt to libqt3-mt and add a conflict with th old name.
This way, you cannot inst
Thanks for your feedback, on the list and irc. Appended is an updated
version, the most notable change is to drop the 'c102' suffix from
packages, if it exists. This way, we get rid off the "ugly" extension,
and we don't support direct upgrades from woody to etch anyway.
Matthias
C++ ABI Tr
Matthias Klose <[EMAIL PROTECTED]> writes:
> * i.e. sparc and hppa. I.e.: hppa libgcc1 (SJLJ) -> libgcc2
> (Dwarf2) transition. I.e.: sparc ABI change from 3.3 to 3.4.
The SPARC ABI changes should only relate to complex numbers or
less used parts of the SPARC64 ABI. Mathmatical packages
I may make sense to also give a timeframe for the transition like
begin -> libraries get uploaded -> libraries get NMUed -> packages get
uploaded -> packages get removed/NMUed. 2-3 weeks for each step? With
some good placed BSPs we could perhaps make this actually happen...
(but of course depends o
In http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html
Steve did talk about "major package changes" in etch. Please find
below the proposal for the C++ ABI transition (and the transition to
GCC 4.0 as the default compiler) for etch. The reason for this posting
is some kind of pre-ap
11 matches
Mail list logo
