On Wed, Dec 12, 2012 at 4:55 AM, Ramana Kumar
Dear Michael, Arch Haskell,
I saw this in the Haskell Weekly News recently: http://www.yesodweb.com/blog/2012/11/stable-vetted-hackage
I would like to propose that Arch Linux and the Hackage-packaging community project therein also be involved :)
Some information about the Arch Haskell project is here https://wiki.archlinux.org/index.php/Haskell_package_guidelines
I believe yesod and its dependencies, for example, are available in our [haskell-web] repository, and we (mainly Fabian and Magnus) are doing a great job of keeping it all working and up-to-date. How might this interface with stackage?
Do you (on either side) see potential for collaboration?
This does indeed look very interesting. Would you, Ramana, have some time to have a closer look at what Michael is working on and see how that would fit with our goal of providing an Arch repo of bleeding edge Haskell packages? How does it affect our existing tooling, etc? (Note that, although it's been fun to write and use, I don't mind retiring 'cblrepo' for something better.) I won't really have time to look into it at the level of detail it deserves due to the workload at my employer at the moment. I had a very cursory glance at what Michael has written about it so far and while it sounds interesting there a few issues that pop into my mind. 1. The set of packages is based on HP, in the past HP has been very slow to move on upgrading, in particular a few of the packages were left on yesteryears versions. This caused problems for us since non-moving packages tend to introduce requirements that limit how far other packages can be upgraded. Is it still the case that HP is this slow to move? How is the Stackage movement planning on countering this? 2. Another issue is that of patching. I personally try to limit the patching, because it is a real time-suck, but sometimes it's not possible to avoid. In most cases I've opted to hold off on the upgrade until upstream have a chance to fix it. However, every such decision has ripple effects---non-upgradable packages have dependencies that prevent upgrading of other packages (same thing as with HP above). How will this be dealt with in Stackage, will old versions of packages be patched to allow upgrades of other packages in the set? 3. Is inclusion in Stackage a one-way road, can a package be removed? (This ties in with #2.) Upstream developers can sometimes be *very* slow with making changes that allow bumping dependencies. Resource limits on our side then prevent us from creating patches ourselves, which again result in preventing upgrades of other packages. It would be lovely to be able to temporarily remove a package from the set, especially if doing so has very few implications on other packages in the set. Other times packages simply become obsolete or unmaintained. This is something that's been discussed a few times, but we've never reached any sort of conclusion. In short, after spending *very* little time looking at it I'm optimistic about Stackage. I think we might have to see how it fits our current goals, but then our goals are *not* set in stone, we've changed them before and can change them again if there are worthwhile benefits to doing so (tapping into a larger community is absolutely one large benefit). /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus