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

27 Jul 2012

      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,   wrote:
...
On 2012-Jun-12, Mateusz Loskot wrote:
...
On 12 June 2012 11:53, Magnus Therning  wrote:
...
On Tue, Jun 12, 2012 at 12:07 PM, Mateusz Loskot  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@therning.org   jabber: magnus@therning.org
twitter: magthe               http://therning.org/magnus
_______________________________________________
arch-haskell mailing list
arch-haskell@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  []

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

gdweber＠iue.edu