| Summary: | virtual/ghc default causes self-blocking issues | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | William Xu <william.xwl> |
| Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | askwar, haskell, jakub, konstantin.sobolev, zlin |
| Priority: | High | ||
| Version: | 2.1 | ||
| Hardware: | PPC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | ghc-6.6 won't compile | ||
|
Description
William Xu
2007-08-08 07:46:33 UTC
The whole problem is that virtual/ghc defaults to dev-lang/ghc-bin; change it to dev-lang/ghc and it works. Portage-wise, looks like dupe of Bug 1343 to me. Any reason why not change the default virtual (or convert this to new-style one even)? # echo "virtual/ghc dev-lang/ghc" >> /etc/portage/profile/virtuals # emerge -pv darcs These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] dev-lang/ghc-6.6.1 USE="-binary -doc -ghcbootstrap" 29,760 kB [ebuild N ] dev-haskell/cabal-1.1.6.2 USE="-doc -profile" 537 kB [ebuild N ] dev-haskell/quickcheck-1.0.1 USE="-doc -profile" 1,884 kB [ebuild N ] dev-haskell/html-1.0.1 USE="-doc -profile" 0 kB [ebuild N ] dev-haskell/mtl-1.0.1 USE="-doc -profile" 0 kB [ebuild N ] dev-util/darcs-1.0.9 USE="-doc" 1,035 kB I suggest changing ${PORTDIR}/profiles/base/virtuals so that dev-lang/ghc is the default provider.
@haskell herd: is there any reason not make dev-lang/ghc the default provider? It seems like ghc-bin will be pulled in by dependencies if necessary so it shouldn't need to be the default provider, should it?
Created attachment 127255 [details]
ghc-6.6 won't compile
Hi Jakub, With your suggestion, no blocking now. But it won't compile. (See about attachment) I've tested and I see that it doesn't pull in ghc-bin like it's supposed to when installing one of the older versions of ghc that requires it. However, it did work if I change the ghc-6.4.2 dep to DEPEND="|| ( <dev-lang/ghc-bin-6.5 <virtual/ghc-6.5 )". A new-style virtual should also work, like Jakub suggested. (In reply to comment #4) > But it won't compile. (See about attachment) Not here; file a separate bug, completely unrelated. The reason that the virtual/ghc must default to ghc-bin is that the ghc source ebuild depends on virtual/ghc and ghc needs a version of ghc to build with, so it must pull in ghc-bin first to bootstrap. We cannot use a new style virtual (we have tried) because bootstrapping does not work correctly that way. The portage devs have confirmed to us previously that this is the intended behavior of new style virtuals and we should continue to use the old style ones (or move to a totally new system...). Similarly having ghc dep on || ( dev-lang/ghc-bin dev-lang/ghc ) does not work since for exactly the same reason the new style virtual does not work (that's effectively just an inlined new style virtual dep). Now because these virtual deps and the ghc/ghc-bin split just causes insanity we have move to a new system for ghc-6.6 and above. We now have a single dev-lang/ghc ebuild which internally uses a .tbz2 binary build of ghc to compile ghc from source. Remember, ghc needs ghc to build. So we are now in a transitionary phase, the stable ghc-6.4.x and below use the old virtual. The new ghc-6.6.x provides the virtual so existing libs can still build but it does not depend on virtual/ghc any more. Our plan was to get ghc-6.6.1 stable and then eliminate the virtual completely, changing all deps to be dev-lang/ghc and merging ghc-bin into ghc for the older 6.4.2 and 6.2.2 ebuilds. However, we had to make the new ghc block on ghc-bin since they install some of the same files, so we can't let them be installed at the same time. The solution is to unmerge ghc-bin-6.4.2 and emerge ghg-6.6.x If anyone has any better suggestions we'd very much like to hear them. BTW, just to be clear: We cannot change the default provider for virtual/ghc. That would make it impossible for people to bootstrap ghc (ie emerge it if they did not already have ghc-bin or ghc installed). Actually, I'm not sure I understand what's going on in the example in the original report. What I don't understand is what is pulling in ghc-bin. The user is using ~ppc keywords and emerging darcs. darcs depends on >=virtual/ghc-6.2.2. dev-lang/ghc-6.6 provides virtual/ghc. There is no dev-lang/ghc-bin-6.6. dev-lang/ghc-6.6 does not depend on virtual/ghc. So what depends on ghc-bin? Looks like portage pulls in ghc-bin because of virtual/ghc even though nothing needs it. We can't remove the block ghc-6.6 has against ghc-bin at the moment. They really do clash. So perhaps the best solution is to accelerate our plan to eliminate virtual/ghc. We could do that by merging ghc-bin into ghc for 6.4.2 and 6.2.2. (We've already got these ebuilds waiting in our overlay) and go round and change all uses of virtual/ghc to dev-lang/ghc. And p.mask ghc-bin. And then eliminate virtual/ghc from the profiles and have the ghc ebuilds stop providing it. We were worried this would cause more disruption since users of stable ghc-bin-6.4.2 would have to move to stable ghc-6.4.2 and then only in a few weeks move to ghc-6.6.1 when that goes stable. But if it's borken right now then fixing that takes precedence. BTW, the other temporary fix is to emerge ghc-6.6.x and then emerge darcs. (In reply to comment #7) > The reason that the virtual/ghc must default to ghc-bin is that the ghc source > ebuild depends on virtual/ghc and ghc needs a version of ghc to build with, so > it must pull in ghc-bin first to bootstrap. Then your dependency tree is broken; ghc does not depend on ghc-bin. (In reply to comment #10) > (In reply to comment #7) > > The reason that the virtual/ghc must default to ghc-bin is that the ghc source > > ebuild depends on virtual/ghc and ghc needs a version of ghc to build with, so > > it must pull in ghc-bin first to bootstrap. > > Then your dependency tree is broken; ghc does not depend on ghc-bin. As I say, we're changing systems, so ghc-6.6.x does not depend on virtual/ghc. The system used in the current stable ghc-6.4.2 and 6.2.2 does depend on virtual/ghc and so that needs ghc-bin to bootstrap. It's that older case that requires the virtual to default to ghc-bin. As a fix for this package, we have changed the dependency virtual/ghc into simply dev-lang/ghc. This should fix the issue at least for this package. We would have done this eventually anyway. If you like to avoid build ghc from source, emerge ghc with USE="binary" emerge ghc which will install a pre-compiled version, just as ghc-bin does. William, I've also tried to fix your issue with ghc not compiling. Please sync your reposes and try again. (In reply to comment #12) > As a fix for this package, we have changed the dependency virtual/ghc into > simply dev-lang/ghc. This should fix the issue at least for this package. We > would have done this eventually anyway. > If you like to avoid build ghc from source, emerge ghc with > USE="binary" emerge ghc > which will install a pre-compiled version, just as ghc-bin does. Yes, i can install pre-compiled version now. > William, I've also tried to fix your issue with ghc not compiling. Compiling ghc or darcs both still fail. Even with the pre-compiled ghc-bin, darcs won't compile. (In reply to comment #13) > Compiling ghc or darcs both still fail. Even with the pre-compiled > ghc-bin, darcs won't compile. Please file a separate bug. *** This bug has been marked as a duplicate of bug 1343 *** *** Bug 197570 has been marked as a duplicate of this bug. *** *** Bug 197772 has been marked as a duplicate of this bug. *** Nothing in portage depends on virtual/ghc anymore except ghc itself and that's always worked. This change was made in the last day, so people still having trouble should sync and see if it goes away. If it does not, please report it here. We'll also be switching over to the unified ghc ebuilds that will not depend on virual/ghc at all. We already did that with ghc-6.6.1 and we'll be doing the same for ghc-6.2.2 and 6.4.2 just as soon as we've finished testing. Then nothing at all will depend on ghc-bin and we can remove the virtual and mask ghc-bin. |
