On Mon, Apr 26, 2010 at 10:49:03AM -0400, Jack Howarth wrote:
>    I should also have added that when I tried to
> add...
> 
> Conflicts: gcc42 (<= 4.2.4-1002), gcc43 (<= 4.3.4-1000), gcc44 (<= 
> 4.4.2-1000), gcc45 (<= 4.5.0-1000)
> 
> alone to the main gcc46 package, this produced the error...
> 
> fink install gcc46
> Password:
> Information about 8703 packages read in 2 seconds.
> The following package will be installed or updated:
>  gcc46
> Reading buildlock packages...
> Could not resolve inconsistent dependencies!
> 
> Fink isn't sure how to install the above packages safely. You may be able to 
> fix things by running:
> 
>   fink scanpackages
>   sudo apt-get update
>   sudo apt-get install gcc46=4.5.999-20100423
> 
> Failed: Fink::SysState: Could not resolve inconsistent dependencies
> 
> I think having this work in fink is the only way to solve
> the problem of converting from a two-way to a three-way split for
> gcc4x. Since the old two-way packages won't know that the gcc4x
> main package from the newer three-way packages doesn't conflict,
> we have to have...
> 
> Conflicts: gcc42 (<= 4.2.4-1002), gcc43 (<= 4.3.4-1000), gcc44 (<= 
> 4.4.2-1000), gcc45 (<= 4.5.0-1000)
> 
> in both the gcc4x and gcc4x-bin split-off for the new three-way
> packages (such that the older gcc4x packages are always
> deinstalled when either the gcc4x or gcc4x-bin packages of
> the new three-way split is installed.
>    Any idea why adding the Conflict to gcc4x in the new three-way
> confuses fink so badly (instead of just forcing the older gcc4x
> package to deinstall)?

Conflicts:foo only forces-out foo if foo is also listed in Replaces.
One cleaner solution would be to have the gcc4x packages remain the
directly-available binaries (generic names in PATH) and put the
hidden/buried ones in a new package-name ("gcc4x-compiler"?). That way
the gcc4x would remain mutually-exclusive and the same "they all
conflicts/replaces each other" as now, so no new upgrade headache for
the new layout. Someone previously mentioned that this approach would
also avoid having to fix every existing package that expects a
dependency on gcc4x to supply the compilers in PATH. What is the
advantage to any advantage to changing that expectation by switching
to the the gcc4x-bin layout idea as you have envisioned?

dan

-- 
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks


------------------------------------------------------------------------------
_______________________________________________
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

Reply via email to