Re: [Fink-devel] co-existing gcc4x packages

2010-04-25 Thread Martin Costabel
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

Re: [Fink-devel] co-existing gcc4x packages

2010-04-25 Thread Jack Howarth
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

Re: [Fink-devel] co-existing gcc4x packages

2010-04-25 Thread Jean-François Mertens
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

Re: [Fink-devel] co-existing gcc4x packages

2010-04-25 Thread Martin Costabel
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

Re: [Fink-devel] co-existing gcc4x packages

2010-04-25 Thread Jack Howarth
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.

Re: [Fink-devel] co-existing gcc4x packages

2010-04-25 Thread Jack Howarth
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

Re: [Fink-devel] co-existing gcc4x packages

2010-04-25 Thread Jack Howarth
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

[Fink-devel] co-existing gcc4x packages

2010-04-24 Thread Jack Howarth
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

Re: [Fink-devel] co-existing gcc4x packages

2010-04-24 Thread Jack Howarth
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,

Re: [Fink-devel] co-existing gcc4x packages

2010-04-24 Thread Jack Howarth
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,

Re: [Fink-devel] co-existing gcc4x packages

2010-04-24 Thread Jack Howarth
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: