Jack Howarth wrote:
[]
What I am considering is to add a gcc4X-bin
split-off to all of the gcc4X packages which
will contain all of the %/bin symlinks currently
provided by the main gcc4X package.
Why do we neeed *any* of these executables directly in %p/bin?
They could as well live in
On Sun, Apr 25, 2010 at 09:46:51AM +0200, Martin Costabel wrote:
Jack Howarth wrote:
[]
What I am considering is to add a gcc4X-bin
split-off to all of the gcc4X packages which
will contain all of the %/bin symlinks currently
provided by the main gcc4X package.
Why do we neeed *any* of
On 25 Apr 2010, at 02:09, Jack Howarth wrote:
What I am considering is to add a gcc4X-bin
split-off to all of the gcc4X packages which
will contain all of the %/bin symlinks currently
provided by the main gcc4X package.
I would think the easiest way to manage such a transition
would be to
Jack Howarth wrote:
On Sun, Apr 25, 2010 at 09:46:51AM +0200, Martin Costabel wrote:
Jack Howarth wrote:
[]
What I am considering is to add a gcc4X-bin
split-off to all of the gcc4X packages which
will contain all of the %/bin symlinks currently
provided by the main gcc4X package.
Why
On Sun, Apr 25, 2010 at 02:24:45AM +0200, Jean-François Mertens wrote:
On 25 Apr 2010, at 02:09, Jack Howarth wrote:
What I am considering is to add a gcc4X-bin
split-off to all of the gcc4X packages which
will contain all of the %/bin symlinks currently
provided by the main gcc4X package.
On Sun, Apr 25, 2010 at 04:56:48PM +0200, Martin Costabel wrote:
Jack Howarth wrote:
On Sun, Apr 25, 2010 at 09:46:51AM +0200, Martin Costabel wrote:
Jack Howarth wrote:
[]
What I am considering is to add a gcc4X-bin
split-off to all of the gcc4X packages which
will contain all of the
On Sun, Apr 25, 2010 at 04:56:48PM +0200, Martin Costabel wrote:
Jack Howarth wrote:
On Sun, Apr 25, 2010 at 09:46:51AM +0200, Martin Costabel wrote:
Jack Howarth wrote:
[]
What I am considering is to add a gcc4X-bin
split-off to all of the gcc4X packages which
will contain all of the
I am thinking about converting the gcc4X packages
into a form that can coexist without reinstallation.
Over the years, I've had a few requests for this.
More importantly, when the new llvm-clang (which
replaces llvm) and dragonegg-gcc packaging enters
unstable, it would be helpful for the gcc4X
Opps. This should be...
--- gcc46-x86_64.info.current 2010-04-24 19:50:20.0 -0400
+++ gcc46-x86_64.info 2010-04-24 20:18:05.0 -0400
@@ -13,8 +13,8 @@
Architecture: x86_64
NoSetCPPFLAGS: True
NoSetLDFLAGS: True
-Conflicts: gcc4, gcc42, gcc43, gcc44, gcc45
-Replaces: gcc4,
If I use the same approach as the dbXX package, a change like...
--- gcc46-x86_64.info.current 2010-04-24 19:50:20.0 -0400
+++ gcc46-x86_64.info 2010-04-24 22:03:32.0 -0400
@@ -13,8 +13,8 @@
Architecture: x86_64
NoSetCPPFLAGS: True
NoSetLDFLAGS: True
-Conflicts: gcc4,
Yuck. This really gets ugly fast. A minimal handling of
the info and manpages makes the changes look like...
--- gcc46-x86_64.info.current 2010-04-24 19:50:20.0 -0400
+++ gcc46-x86_64.info 2010-04-24 22:30:21.0 -0400
@@ -13,12 +13,12 @@
Architecture: x86_64
NoSetCPPFLAGS:
11 matches
Mail list logo