[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: haskell-qt



Hi,

Am Sonntag, den 29.05.2011, 20:55 +0200 schrieb Filip Brcic:
> On Saturday, 28. May 2011. 21.39.35 Joachim Breitner wrote:
> > thanks. Did you install the commit hooks (as mentioned on
> > http://wiki.debian.org/Haskell/CollabMaint/DarcsBasic)? I think you have
> > to run the commands on vasks now.
> 
> Nope, I get the strange error:
> 
> $ ssh alioth.debian.org /darcs/pkg-haskell/tools/add-hooks.sh haskell-qt
> Permission denied (publickey).
> 
> Now I tried it on vasks.debian.org and got the same error, but it worked on 
> darcs.debian.org, so now I have installed the hooks :)

It is still not clear to me what needs to be done on vasks and what on
wagner. But I assume that the repos are read-only on one of them two,
and therefore the other host is correct :-)

> > Also, its the first time I see the creation of a libhaskell-qt package
> > for the C bits. What is the rationale for not putting the stuff in
> > the-dev package? (I’m not doubting you here, I’m just curious :-)) Is it
> > so that binaries created from haskell-qt need only libhaskell-qt
> > installed, but not libghc-qt-dev?
> 
> libhaskell-qt supplies several .so libraries that are linked to all qtHaskell 
> packages. Since currently there are no packages that depend on qtHaskell, the 
> library is not needed by anyone except libghc-qt-dev, yet if some packages are 
> to be built depending on qtHaskell, they'll need to depend on libhaskell-qt. I 
> guess it is nicer to pull a ~3mb library package than the whole -dev only for 
> a program to run. :)

Yes, that is reasonable.

> > I’ll not find the time to completely review the package now, and will be
> > busy tomorrow and probably Monday. Maybe someone else in the DHG can
> > jump in, to not scare Filip away by long delays? :-)
> 
> I just updated the build system. I was looking into the supplied make files and 
> figured out that by running them the package compiles 10-20 times faster. 
> Probably because the setup.hs loads the whole library into memory and 
> generally fills up the computer memory (at least on my laptop with 4 g ram). It 
> took me about 12 hours to compile the package by using regular setup.hs, and 
> by using the makefiles (that are invoked by build.pl script) it takes about an 
> hour or less. If you believe running setup.hs is safer, it is easy to drop the 
> build-ghc-stamp override from the rules file.

Well, I think upstream knows what he is doing. And as long as the
pkg-pkg file is properly created and the hash-based Provides and Depends
are in place, I think we are fine.

I am offline at the time of writing, so I cannot have a look at the new
package.

And could you encourage upstream to put their package on Hackage
nevertheless, even if it does not build there? Also for their own sake,
as it gives them more expose. Also, they could modify Setup.sh using the
hooks to use their smarter build system with the usual interface. But I
digress, and this is in no way a condition for inclusion in Debian.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: