On Tue, Apr 27, 2010 at 09:24:42AM -0500, Peter O'Gorman wrote:
> On 04/27/2010 12:08 AM, Jack Howarth wrote:
> > I've posted test packaging for a gcc45-4.5.0-1001
> > and gcc45-compiler-4.5-1 package on fink tracking...
> >
> > https://sourceforge.net/tracker/?func=detail&aid=2992713&group_id=17203&atid=414256
> >
> > The new gcc45 packaging...
> >
> > 1) Moves all of the currently conflicting files between the gcc4x packages
> > into a new gcc4x-compiler package which recreates them with symlinks.
> > 2) Builds the compiler programs with the -fsf-4.x suffix and presents these
> > program names in %p/bin via symlinks in the main gcc4x package.
> > 3) Provides all of the original program names in %p/lib/gcc4.x/bin.
> >
> > I've tested this packaging by upgrading from the previous gcc45-4.5.0-1000
> > proposed packaging. A test gcc46 package of the same type was also used to
> > verify that the gcc45/gcc46 packages properly co-exist and that the two
> > gcc45-compiler/gcc46-compiler packages properly switch the default FSF gcc
> > system compiler in %p/bin as well as the associated man and info pages.
> > Jack
>
> Hi Jack,
>
> I don't get it. Why create a new -compiler package with the old compiler
> names as symlinks and require everyone to modify their builddepends?
>
> Can you not do it all in one .info file, install all the symlinks in
> your installscript, and then splitoff the -shlibs and the "real"
> compilers etc., leaving only the old symlinks in the gcc45 package. This
> would keep compatibility with the current packaging while allowing all
> the real compilers to be simultaneously installed.
>
> i.e.
>
> gcc45 package contains all the links you have just put in gcc45-compiler
> gcc45-shlibs contains all the shlibs
> gcc45-toolchain (or some better name) has everything else.
>
> Sorry, I thought that was what you were planning to do, or I would have
> mentioned it yesterday.
>
> Peter
Peter,
The problem is that the current handling of dependencies in
fink doesn't allow that. Read the thread "Could not resolve inconsistent
dependencies" in the fink-devel mailing list. It is impossible to
come up with a split-off strategy that allows for clean upgrades
from the existing gcc4x packages. If there is a lot of push-back
against changing the current and prior gcc4x packages in the same
manner, we could just start this with gcc45 and all future gcc4x
releases.
To recap, the problem with using a single package with split-off
strategy is that both gcc4x and gcc4x-bin would require a Conflicts/
Replaces on the older gcc4x packages which have overlapping files.
This is because the older gcc4x packages can't know that they are
are able co-exist with the newer gcc4x package and will Conflict with it.
This causes dependency failures for fink in the absence of an explicit
Conflicts/Replaces in the new gcc4x package (which is impossible
since gcc4x-bin also needs that). The solution is to move the overlapping
files out of gcc4x into a gcc4x-compiler package and have the new gcc4x
package Conflicts/Replaces with the older gcc4x packages
while the gcc4x-compiler package Depends on a newer gcc4x package which
doesn't have overlapping files.
When you actually start trying to run these upgrades yourself,
you see how impossible the single package approach is.
Jack
ps It isn't like this demands any significant effort from the other
developers. They can just change the existing BuildDepends from
gcc4x to gcc4x-compiler or leave the BuildDepends as gcc4x and
either change the compiler inovations from gcc-4 to gcc-fsf-4.x
or explicitly use the path %p/lin/gcc4.x/bin/gcc-4. I think I've
left everyone with plenty of options here.
I would also note that we would probably be violating fink policy by
trying to add a gcc4x-bin split-off that only contained symlinks.
Also, the reason I want to implement this change is that packages
that currently require the gcc4x package to be present (including
the upcoming dragonegg-gcc package) end up causing fink remove
failures with the use of one gcc4x package requires the removal
of another. My aim is for these packages to never have to be
deinstalled in order to switch the gcc4x in use for a particular
package build.
------------------------------------------------------------------------------
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
