Background: USE=fortran is in the default profile, bug I figured, why spend that extra time in gcc builds if I don't use it? As it turns out, I had a couple of packages (that I could do without) that depended on sys-devel/gcc[fortran], but I discovered this not when changing the USE flags and rebuilding gcc, but when running revdep-rebuild later. Bug: various package do not declare their dependency on sys-devel/gcc[fortran]. A list of likely packages may be generated by this command: $ cd /usr/portage $ grep -l -r inherit.*fortran .
And packages don't declare a dependency on sys-devel[cxx] either. There is virtual/fortran too.
(In reply to comment #1) > And packages don't declare a dependency on sys-devel[cxx] either. The difference is, it's not likely to have a full system without sys-devel/gcc[cxx] (and completely impossible once gcc 4.8 happens), whereas most people can do without fortran. > There is virtual/fortran too. Yeah, that'd be better.
Please file separate bug reports for those packages that lack the dependency, and make those bugs block this one.
You'll have to reopen this if you find time to work on it.
Sorry, I only have time for Gentoo stuff on weekends. I'll be filing dozens of bug reports now ...
Sorry for the noise ... I started filing bug reports before actually checking whether they already *had* the dependency. As it turns out, *most* packages already do have it. In some cases some versions have the inherit but not the depend, but others have only the inherit ... I will not file the bugs in these cases, since the ebuild maintainer is obviously aware of the problem. OTOH I am going to file bug reports for packages where only some versions inherit fortran, but don't have the depend; but other versions have no fortran at all, so the package maintainer can decide whether to fix it or just remove the old ebuilds from the tree.
Okay, the original problem I had is different than I thought: virtual/fortran *is* still installed on my system, because I (somehow) have dev-lang/ekopath installed, but it does not make users of fortran-2.eclass happy without putting special environment variables. It would be better if this were handled by an eselect or something (why is gcc-config not an eselect, anyway?) It's possible that some packages that depend on virtual/fortran really depend only on sys-devel/gcc[fortran] dev-lang/ekopath (formerly dev-lang/ekopath-bin) smells funny: LICENSE="GPL-3" RESTRICT="mirror" it's a binary ELF download and I cannot find any source. -- I'll continue filing the dependency bugs blocking this one. I have no clue what to do about this latest revelation.
That dependency is a bit useless with current way things are interpreted by portage. Nevertheless let's keep it uniform across the tree, hoping it'll be useful someday. If you find more bugs, keep them coming. If that's old, please close the tracker. Thanks!
(In reply to comment #8) > If you find more bugs, keep them coming. If that's old, please close the > tracker. Thanks! I was just getting started, then. That should be everything, now. Things beyond the scope of this bug: * If the package conditionally depends on virtual/fortran, it must override pkg_setup (I did note this when filing the blocking bugs, I just haven't searched the rest of the tree) * Whether the package needs/lists fortran only in DEPEND, or also in RDEPEND * Whether the package really happen with any fortran (assuming proper environment variables are set), or only with sys-devel/gcc[fortran]
(In reply to comment #9) > (In reply to comment #8) > > If you find more bugs, keep them coming. If that's old, please close the > > tracker. Thanks! > I was just getting started, then. That should be everything, now. > Thanks for digging the missing packages. I will work on them when they come in from you > Things beyond the scope of this bug: > * If the package conditionally depends on virtual/fortran, it must override > pkg_setup (I did note this when filing the blocking bugs, I just haven't > searched the rest of the tree) I will create the same thing like python eclass is doing for their pkg_setup(). Thanks for the idea. > * Whether the package needs/lists fortran only in DEPEND, or also in RDEPEND I would think as long as it build shared/dynamically linked objects, we need it in RDEPEND. > * Whether the package really happen with any fortran (assuming proper > environment variables are set), or only with sys-devel/gcc[fortran] I will ask Diego to do some tinderboxing on that.
cvs ci -m "Depend on virtual/fortran eclass wise, #435250" ChangeLog fortran-2.eclass we will depend on it eclass wise.
Wrong, packages with optional fortran support will break.
Now we got it right.
