[arch-haskell] Stable, Vetted Hackage

[Michael Snoyman]

On Fri, Dec 14, 2012 at 10:18 AM, Magnus Therning <magnus at therning.org>wrote:

> 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?
>
>
I think we're going to end up with a few different flavors of Stackage.
Basing on the HP is good for typical end users who have installed the HP,
but might not make much sense for your use case. I've added an option for
Stackage to ignore the HP constraints, which is probably what you're going
to want to do. (Alternatively, you *could* just stick with the HP
constraints, as I don't think they're that onerous, but it's entirely your
decision.)


> 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?
>
>
This will definitely be a feature I add to the Stackage codebase (it's
currently an open issue[1] as I haven't thought through all the
implications yet). But like you said, this can be a time suck.
Additionally, the concept of having a distinction between Hackage's
foo-1.2.3 and Stackage's foo-1.2.3 worries me a bit, but not enough to
avoid putting the feature in.

[1] https://github.com/fpco/stackage/issues/5


> 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.
>
>
Packages can definitely be removed. There are really two categories of
Stackage packages: explicit and implicit. Explicit packages are listed in
Stackage.Config, and implicit ones are their deep dependencies. If an
implicit package is no longer required by any explicit packages, it will be
automatically dropped. We can also remove a package from the explicit list
if the maintainer is unresponsive. So far, I've had great response times
from maintainers. I'm hoping that by making this a centralized community
effort, maintainers will be much more responsive than having individual
Linux distros each making their own sets of requests. (Actually, IME so far
maintainers have been happy to have a solid set of guidelines for improving
their package quality, I'm hoping that trend continues.)

The other tool we have in our disposal is temporary upper version bounds,
e.g. [2]. Having a semi-fixed schedule of about a week to bump version
bounds seems to work pretty well in practice.

[2] https://github.com/fpco/stackage/issues/21


> 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).


I'm glad to hear it, and I'd really love to see Arch move forward with
this. Let me know if you have any other questions, or if you can think of
some tweaks/improvements to Stackage that would help you out.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/arch-haskell/attachments/20121214/e5844e47/attachment-0001.htm>