[arch-haskell] Stable, Vetted Hackage

[Magnus Therning]

On Wed, Dec 12, 2012 at 4:55 AM, Ramana Kumar <ramana at member.fsf.org> wrote:
> 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 at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus