[arch-haskell] Current procedure to install Hakyll (with deps)

[gdweber at iue.edu]

Building the packages for hakyll, hamlet, and kin
turned out to be easier than I expected
-- for some reason, the process automatically selected the right flags
and the right version of blaze-html to depend on.  

However, it seems that what Fabio Riga has done on this
is much farther along than what I've managed to do,
so I think I'm going to abandon this line of effort
and use his packages -- which I hope will soon be
integrated into the main [haskell] repository.

I have a couple of other questions relating to how I might
make any further contributions to the [haskell] repo.

1.  Due to Magnus's preference for taking pre-built packages
and patches, rather than accepting "pull" requests through github,
I'm inclined to think that my maintaining a fork of the
habs project on github is not serving any useful purpose,
and I'm thinking of deleting the fork.  Any objections?

(
This urge to delete is compounded by my unfamiliarity with git and
receiving increasingly bizarre error messages,
for example, today when I tried to push to my own
remote:

     $ git push myfork hakyll
    ...

     ! [rejected]        hakyll -> hakyll (non-fast-forward)
    error: failed to push some refs to 'https://github.com/gdweber/habs.git'
    hint: Updates were rejected because the tip of your current branch is behind
    hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
    hint: before pushing again.
    hint: See the 'Note about fast-forwards' in 'git push --help' for details.

I can't understand how my local branch can be behind the remote,
since I'm the only one pushing to the remote!
I'm really spoiled by darcs, and the more I use git,
the less it makes sense.
)

2.  Also I'm wondering if instead of a fork (or just a clone) of
archhaskell/habs, and a "topic branch" in git for what I want to add,
it might be better to create a completely different repo,
such as Fabio has done for [haskell-extra] --

    https://github.com/EffeErre/habs-extra

-- in which the packages from [haskell] are treated
as "distribution packages" in cblrepo.

What are the pro's and con's of this approach?

Greg

On 2012-Jul-11, Magnus Therning wrote:
> On Wed, Jul 11, 2012 at 12:54 AM,  <gdweber at iue.edu> wrote:
> > On 2012-Jun-12, Mateusz Loskot wrote:
> >> On 12 June 2012 11:53, Magnus Therning <magnus at therning.org> wrote:
> >> > On Tue, Jun 12, 2012 at 12:07 PM, Mateusz Loskot <mateusz at loskot.net> wrote:
> >> > [...]
> >> >> So, here comes my question:
> >> >> Considering I'm interested in Hakyll, could anyone recommend where
> >> >> should I grab all the related packages and required dependencies from?
> >> >
> >> > Don't use AUR!
> >>
> >> OK, I won't.
> >>
> >> > Check to see how many of the dependencies are in [haskell], if all are
> >> > there: profit!
> >>
> >> I will try this option tonight.
> >>
> >> > If only a few are missing you can always raise a bug to
> >> > get them added (I look favourable upon existence of patches +
> >> > pre-built packages).
> >>
> >> I'm usually happy to contribute too, though in case of Haskell I'm
> >> green as Irish grass.
> >
> > I, too find, the Hakyll package interesting.
> >
> > I am interested in contributing a hakyll packages and its missing
> > dependencies, provided I can get some feedback on my previous
> > attempted contribution (of OpenGL).
> >
> > A few questions and comments:
> >
> > 1.  Installing the latest version of Hakyll, 3.3.0.1,
> > would require upgrading blaze-html
> > and reinstalling (probably breaking, warns cabal install --dry-run)
> > pandoc.  It seems best to aim at hakyll 3.2.7.2, which is
> > the latest version that can use blaze-html 0.4.* (we are at 0.4.3.3-5).
> 
> The latest version of blaze-html either requires a few other updates,
> or breaks other packages at the moment.  I can't remember which it is,
> but you can easily see check by attempting to add it using `cblrepo`.
> Settling for an older version of hakyll is all right for the moment.
> 
> > 2.  Hakyll has a "previewServer" flag, which, if True (the default),
> > also depends on snap-core and snap-server.  Making a hakyll package
> > with the previewServer would require 21 new packages, including hakyll
> > itself.  Without the previewServer, it would require only 5 new packages.
> > So I think I would plan *at first* to provide the package *without* the
> > previewServer.
> 
> Good point.
> 
> > 3.  Assuming cblrepo does not automatically set the previewServer
> > flag to False, I think the best way to do this would be a patch
> > for the PKGBUILD?
> 
> Either a patch to the PKGBUILD or a patch to the .cabal.
> 
> If you come up with a good way to pass in flags when running `cblrepo
> add` then please let me know :)
> 
> > 4.  One of the dependencies is hamlet, which requires another flag
> > setting, blaze_html_0_5 to be False, in order to use blaze-html < 0.5.
> > Again, a PKGBUILD patch?
> 
> Or .cabal patch.
> 
> /M
> 
> -- 
> Magnus Therning                      OpenPGP: 0xAB4DFBA4
> email: magnus at therning.org   jabber: magnus at therning.org
> twitter: magthe               http://therning.org/magnus
> 
> _______________________________________________
> arch-haskell mailing list
> arch-haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/arch-haskell

-- 
Gregory D. Weber, Ph. D.                            :
Associate Professor of Informatics                 / \
Indiana University East                           0   :
Tel. (765) 973-8420; FAX (765) 973-8550              / \
http://mypage.iu.edu/~gdweber/                      1  []