Hmm, what we would need is so that when haskell-pandoc is being built it's PKGFILE is updated so that it requires haskell-http 4000.0.9 exactly. Then an attempt to uninstall haskell-hp-http later would require an uninstallation of haskell-pandoc too.
Can pacman be forced to do this? We would need something like a new option in PKGFILE which would have meaning: "fix versions of dependencies of these packages exactly to the versions which are currently installed (installed during building)."
Just for reference, this is basically what the Debian policy on Haskell packages is.
Good policy, if they can have it automated. If pacman (or I should rather say makepkg) has such a option then great. If not we should check whether we can add it there. We want the final exact version for dependency to be fixed during build time. The PKGBUILD files need to contain the version ranges as the cabal files.
If we cannot have this late version fix during makepkg then I say just let it be as it is. If a user wants to go into the troubles with the source packages then he/she should be able to take care about knowing and obeying the haskell quirks.
Well maybe we could try to provide a small wraper over makepkg (something like haskell-makepkg) which should be used for haskell source packages ... if we cannot get this fixed in the makepkg itself.
A few weeks I hacked makepkg to add this very feature, I didn't took time to test it exhaustively nor to propose it to the authors.
Why are we trying to resolve a problem that we've already solved through discussion previously? The idea was to provide a consistent set of PKGBUILDs with topological rebuilds and updates. There is no reason to hack makepkg with post-install version changes and other nastiness. We should provide a full set of PKGBUILDs that specify dependencies via specific versions (when necessary, which may be always). Topological updates will then propagate down the dep chain as necessary. All topological updates will be released simultaneously and thus the user updates all affected packages at once. Wouldn't this solve the problem? The idea that I originally proposed was to "abandon" the AUR in favor of our own repository of PKGBUILDs and local source files (alongside a binary repo). On the AUR, we have to worry about maintaining a monopoly of Haskell packages for this to work (e.g. to avoid breaking others' packages and to make sure that all of our deps are under our control). I think we should have a simple online directory of the latest PKGBUILDs and local source files that people can download just as they download from the AUR. All it needs is a simple layout (e.g. "/pkgbuilds/{haskell-foo,haskell-bar,haskell-baz,etc}" and maybe some JSON interface for building tools. This seems far simpler than getting a patch into makepkg to enable us to kludge our way through this. Maintenance of anything outside of that repo will be left up to the respective maintainers. Our goal isn't to get everyone to cooperate, it's to provide an internally consistent set of packages for the users. I will of course help to provide tools for automatically building packages from this PKGBUILD repo (bauerbill integration initially, then support in its replacement when I have it, along with whatever other tools might be useful). Now, to be less abstract, let's talk about some goals and code. Our goals right now seem to be to provide the latest official version of the Haskell Platform and in parallel provide the latest working set of all packages. We should be able to generate a dependency graph to track versions for both of these sets and use that for topological rebuilds. We then need update scripts that bump versions, update the graph, then regenerate PKGBUILDs (and rebuild binary packages) when necessary before pushing everything to our repo (source and/or binary). If someone can provide me a way to determine the versions that belong to these sets then I can start working on something to create repo and handle the topological rebuilds/PKGBUILD bumps. We can upload that on the kiwilight server alongside the binary repo.* If we really want to maintain the arch-haskell presence on the AUR then I suggest that we get the separate PKGBUILD repo working as a proof-of-principle. Once we have that, we could make an argument for re-establishing a monopoly of haskell packages on the AUR. Really though, the only advantage that I see in using the AUR is that it's familiar to many users. We can easily achieve familiarity with our own repo, at least among Haskell users, through a few announcement and user-friendly tools, which I believe we can provide. /Xyne * That gives me an idea... I'm going to ask Kaiting if we can have an arch-haskell account on the server so that we can share access to the repo and whatever else we want on there. It could be a good droppoint for collaboration on other things too. I'll post an update once I get a response.