Edward Kmett
One much weaker consideration is that out of the 23+ direct dependencies on fgl, fully half of them don't bother to specify an upper bound on the fgl version and would break immediately. That said, those packages are out of compliance with package versioning policy. =)
From what I can tell, fgl is more often used for internal projects or executables rather than to create actual libraries. So the whole
I've contacted all the maintainers of those packages, and have received replies from all but two maintainers promising to fix theirs (still haven't heard from Aditya Mahajan for teams and John Morrice for esotericbot). Note that I'm just as guilty in this regard as I have three packages that depend on fgl without upper bounds... >_> I don't know how many of them have released fixed versions yet (I know I haven't), but with the whole two versions of FGL needed thing: we're going to work hard to help maintainers of packages that use FGL to upgrade to the new version once we're satisfied with it and decide to make the release official. As such, we shouldn't have any problems of packages depending transitively on two versions of FGL because most if not all of them will get upgraded. With FGL, we also have the situation where we have a "famous" library that isn't actually used much: * Out of those 23 direct dependencies on Hackage, 3 of them were by old versions of packages (i.e. they no longer use fgl); these are mpc, jhc and lhc. * One is officially deprecated (scenegraph). * 10 are pure libraries (note that some of these have no reverse dependencies, or if they do it's only by a few packages) (note that I included a package here if its executable seemed to only be for tests). * 6 are executables only. * 3 seem to be a library + an executable; only one of these has a reverse dependency and even then by one other package. Out of the 25 indirect reverse dependencies: * 20 (some of which are older versions only and thus not the latest) may transitively depend upon the old version of mps (either directly or via the hack library); because the dependencies on mps, etc. are open-ended for many of these it's difficult to tell if a new install will still transitively require fgl (as in to actually get it to work). * 1 dependency on cabal-macosx * 2 dependencies on lambdacube-engine (other lambdacube projects) * 2 satchmo projects depending (transitively in one case) upon funsat. As such, if we only consider transitive dependencies, then this issue of one package using new and another old fgl is a non-issue as in all cases as there's only a single point of contact with fgl. problem of worrying about multiple versions appears to be (no offense to anyone) scare-mongering (or looking for possible problems due to bad experiences with parsec, etc.). With the 4 transitive dependencies on fgl above, I'm not sure how many of them actually see any aspects of fgl or if its all hidden inside the internal API of whatever package they use. Thus, once packages have proper reverse dependencies in their .cabal files (as they should), then we should not really have a problem here if a few packages don't upgrade at the same time or at all (except for cases where a distribution only ships one version of each library and wants to ship two different packages that depend upon different versions of fgl). Once again: we're going to do our very best to avoid the issues that arose when parsec, QuickCheck, etc. had new major versions released and packages transitively depended upon two different versions; however if it does arise then it's going to be a very small localised problem. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com