Problems with Haskell Platform

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Problems with Haskell Platform

Dominic Steinitz-2
I seem to be in some sort package dependency hell (which I thought the
Haskell Platform did away with).

I install ghc using my package manager (I'm on opensuse).

> dom1@fourier:~> ghc --version
> The Glorious Glasgow Haskell Compilation System, version 6.12.1
> dom1@fourier:~> cabal --version
> cabal-install version 0.8.2
> using version 1.8.0.4 of the Cabal library
> dom1@fourier:~> cabal update
> Downloading the latest package list from hackage.haskell.org
But

> dom1@fourier:~> cabal upgrade cabal-install
> Resolving dependencies...
> Downloading HTTP-4000.0.9...
> Configuring HTTP-4000.0.9...
> Preprocessing library HTTP-4000.0.9...
> Building HTTP-4000.0.9...
>
> Network/StreamSocket.hs:30:7:
>     Could not find module `Network.Socket':
>       There are files missing in the `network-2.2.1.7' package,
>       try running 'ghc-pkg check'.
>       Use -v to see a list of the files searched for.
> cabal: Error: some packages failed to install:
> HTTP-4000.0.9 failed during the building phase. The exception was:
> ExitFailure 1
> cabal-install-0.8.2 depends on HTTP-4000.0.9 which failed to install.
And trying to install the Haskell Platform via
http://hackage.haskell.org/platform/2010.1.0.0/cabal/haskell-platform-2010.1.0.0.tar.gz

> dom1@fourier:~> cabal install
> Resolving dependencies...
> cabal: dependencies conflict: ghc-6.12.1 requires directory ==1.0.1.1
> however
> directory-1.0.1.1 was excluded because ghc-6.12.1 requires directory
> ==1.0.1.0
Which is somewhat baffling.

So I uninstalled ghc via the package manager and downloaded the linux
binaries at
http://haskell.org/ghc/dist/6.12.1/ghc-6.12.1-i386-unknown-linux-n.tar.bz2

But sadly

> dom1@fourier:~/Downloads/ghc-6.12.1> ./configure
> checking for path to top of build tree... ./configure: line 1687:
> utils/ghc-pwd/ghc-pwd: cannot execute binary file
> configure: error: cannot determine current directory
And indeed it is true

> dom1@fourier:~/Downloads/ghc-6.12.1> utils/ghc-pwd/ghc-pwd
> bash: utils/ghc-pwd/ghc-pwd: cannot execute binary file
I'm not sure where to go from here. I think my options are a) build ghc
from source or b) find the source for ghc-pwd and compile it and then
try configure again.

Any help would be appreciated.

Dominic.






_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Problems with Haskell Platform

Yitzchak Gale
Dominic Steintiz wrote:
> I seem to be in some sort package dependency hell (which I thought the
> Haskell Platform did away with).
> I install ghc using my package manager (I'm on opensuse)...
> But
>> dom1@fourier:~> cabal upgrade cabal-install

A while back I had a similar problem. I was instructed by
the Cabal cabal never to use "cabal upgrade", it's
broken. Use "cabal install --reinstall" instead.

Hope this helps,
Yitz
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Problems with Haskell Platform

Dominic Steinitz-2
Yitzchak Gale wrote:

> Dominic Steintiz wrote:
>  
>> I seem to be in some sort package dependency hell (which I thought the
>> Haskell Platform did away with).
>> I install ghc using my package manager (I'm on opensuse)...
>> But
>>    
>>> dom1@fourier:~> cabal upgrade cabal-install
>>>      
>
> A while back I had a similar problem. I was instructed by
> the Cabal cabal never to use "cabal upgrade", it's
> broken. Use "cabal install --reinstall" instead.
>
> Hope this helps,
> Yitz
>
>  
Hi Yitz,

Thanks for this. It turned out that there were some old files in
/usr/lib/ghc-6.12.1/package.conf.d/* which were confusing ghc-pkg and
cabal. I deleted these and re-installed ghc via the package manager and
I am now back working (although not on the Haskell Platform afaik). All
I had wanted to do was install the "statistics" package and 3 hours
later I had ;-)

Dominic.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Problems with Haskell Platform

Bugzilla from 1@234.cx
In reply to this post by Dominic Steinitz-2
Dominic Steintiz wrote:

> I seem to be in some sort package dependency hell (which I thought the
> Haskell Platform did away with).
>
> I install ghc using my package manager (I'm on opensuse).

I was just thinking, interactions between Cabal and the distribution
package manager could get worse, as shared Haskell libraries become more
common.  Suppose a distribution ships a package 'foo', but not a package
'bar' which depends on it.  The 'foo' package includes shared libraries.
  The user now installs 'bar' using Cabal.  This causes Cabal to install
'foo' (because it is a dependency) and it won't use the distribution's
package manager.

If 'foo' is built as a shared library, programs built by the user will
not work for anyone else.  Other users will have the distribution's
build of 'foo' rather than Cabal's build.  If 'foo' is built statically,
it's not quite so bad, but the user will not get the benefits that could
come from using shared libraries.

Pete

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Problems with Haskell Platform

Ivan Lazar Miljenovic
On 31 May 2010 20:14, Pete Chown <[hidden email]> wrote:
> I was just thinking, interactions between Cabal and the distribution package
> manager could get worse, as shared Haskell libraries become more common.
>  Suppose a distribution ships a package 'foo', but not a package 'bar' which
> depends on it.  The 'foo' package includes shared libraries.  The user now
> installs 'bar' using Cabal.  This causes Cabal to install 'foo' (because it
> is a dependency) and it won't use the distribution's package manager.

Why won't it?  This, of course, depends on how the distribution ships
`foo' in regards to static/shared libraries and what the user's
options to Cabal/cabal-install are.

In Gentoo, for example, we at the moment only build static libraries,
mainly because there has been no pressing need/request for shared
libraries; however it would definitely be possible to add support for
them (might be difficult dependency-wise if shared library support it
optional, but this is also a problem we haven't resolved yet for
profiling libraries).

> If 'foo' is built as a shared library, programs built by the user will not
> work for anyone else.  Other users will have the distribution's build of
> 'foo' rather than Cabal's build.  If 'foo' is built statically, it's not
> quite so bad, but the user will not get the benefits that could come from
> using shared libraries.

In general, even if some application is built statically then it won't
work on other machines due to different C library versions (GMP,
etc.), so I don't think this is such a big deal.

Of course, the big thing here is whether Linux distributions, etc.
should ship static or shared libraries by default.

--
Ivan Lazar Miljenovic
[hidden email]
IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Problems with Haskell Platform

Bugzilla from 1@234.cx
Ivan Miljenovic wrote:

> Pete Chown <[hidden email]> wrote:

>> ... This causes Cabal to install 'foo' (because it
>> is a dependency) and it won't use the distribution's package manager.

> Why won't it?  This, of course, depends on how the distribution ships
> `foo' in regards to static/shared libraries and what the user's
> options to Cabal/cabal-install are.

Is there a way of making Cabal install dependencies using the system
package manager, then?

For example, I might ask Cabal to install package A.  Package A depends
on B and C.  A package for B can be downloaded through APT, but there
are no APT-installable candidates for A and C.  Are you saying that
Cabal can download and install B using APT, then download A and C from
Hackage?

> In general, even if some application is built statically then it won't
> work on other machines due to different C library versions (GMP,
> etc.), so I don't think this is such a big deal.

Your program should run on other machines that use the same Linux
distribution, though.  The problem is that this won't happen if Cabal
ends up building its own shared libraries.  For simplicity, let's have a
new example...  The user asks Cabal to install package X, so Cabal goes
to Hackage and gets the latest version, 1.2.3.5.  It builds shared
libraries from it.  Meanwhile, the distribution actually packaged X
version 1.2.3.4.  The user's programs could have been linked against
1.2.3.4, and then they would have run on all systems using that
distribution.  As it is, the programs only work on the user's own
machine, because that's the only machine with the 1.2.3.5 shared library.

One option is to stop Cabal building shared libraries.  That would avoid
the worst of these problems, but it would still be sub-optimal.  The
user might want to link against shared libraries, but he won't have the
chance, because he installed X from the wrong place.

(I believe current versions of ghc insist on linking entirely
dynamically or entirely statically.  This makes the situation worse,
because the lack of a shared library for X prevents the use of shared
libraries for anything else.)

> Of course, the big thing here is whether Linux distributions, etc.
> should ship static or shared libraries by default.

With other languages they tend to ship both, and give the user the
choice, I suppose.

Pete

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Problems with Haskell Platform

Ivan Lazar Miljenovic
Pete Chown <[hidden email]> writes:

> Ivan Miljenovic wrote:
>
>> Pete Chown <[hidden email]> wrote:
>
>>> ... This causes Cabal to install 'foo' (because it
>>> is a dependency) and it won't use the distribution's package manager.
>
>> Why won't it?  This, of course, depends on how the distribution ships
>> `foo' in regards to static/shared libraries and what the user's
>> options to Cabal/cabal-install are.
>
> Is there a way of making Cabal install dependencies using the system
> package manager, then?
>
> For example, I might ask Cabal to install package A.  Package A
> depends on B and C.  A package for B can be downloaded through APT,
> but there are no APT-installable candidates for A and C.  Are you
> saying that Cabal can download and install B using APT, then download
> A and C from Hackage?

If you mean cabal-install, then no, there's no integration on either
side.

>> In general, even if some application is built statically then it won't
>> work on other machines due to different C library versions (GMP,
>> etc.), so I don't think this is such a big deal.
>
> Your program should run on other machines that use the same Linux
> distribution, though.  The problem is that this won't happen if Cabal
> ends up building its own shared libraries.  For simplicity, let's have
> a new example...  The user asks Cabal to install package X, so Cabal
> goes to Hackage and gets the latest version, 1.2.3.5.  It builds
> shared libraries from it.  Meanwhile, the distribution actually
> packaged X version 1.2.3.4.  The user's programs could have been
> linked against 1.2.3.4, and then they would have run on all systems
> using that distribution.  As it is, the programs only work on the
> user's own machine, because that's the only machine with the 1.2.3.5
> shared library.

This is exactly the same with C programs.

> One option is to stop Cabal building shared libraries.  That would
> avoid the worst of these problems, but it would still be sub-optimal.
> The user might want to link against shared libraries, but he won't
> have the chance, because he installed X from the wrong place.
>
> (I believe current versions of ghc insist on linking entirely
> dynamically or entirely statically.  This makes the situation worse,
> because the lack of a shared library for X prevents the use of shared
> libraries for anything else.)

No, 6.12 defaults to statically but allows dynamic linking as well.

>> Of course, the big thing here is whether Linux distributions, etc.
>> should ship static or shared libraries by default.
>
> With other languages they tend to ship both, and give the user the
> choice, I suppose.

Really?  For C, Gentoo ships very few which either default or have the
option of static libraries, and I assume the same is true for binary
distributions.

--
Ivan Lazar Miljenovic
[hidden email]
IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Problems with Haskell Platform

Ben Millwood
On Wed, Jun 2, 2010 at 12:37 PM, Ivan Lazar Miljenovic
<[hidden email]> wrote:

>>
>> Is there a way of making Cabal install dependencies using the system
>> package manager, then?
>>
>> For example, I might ask Cabal to install package A.  Package A
>> depends on B and C.  A package for B can be downloaded through APT,
>> but there are no APT-installable candidates for A and C.  Are you
>> saying that Cabal can download and install B using APT, then download
>> A and C from Hackage?
>
> If you mean cabal-install, then no, there's no integration on either
> side.
>

It's worth noting, though, that cabal-install doesn't track installed
packages itself, GHC does. So if you install a library from APT and it
writes to the package.conf correctly, cabal-install will be able to
find it.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Problems with Haskell Platform

Ivan Lazar Miljenovic
On 3 June 2010 00:37, Ben Millwood <[hidden email]> wrote:
> It's worth noting, though, that cabal-install doesn't track installed
> packages itself, GHC does.

And this is why cabal-install can't tell you when there are new
versions of executable-only packages (e.g. happy) available: it
doesn't even know that happy is installed let alone what version is
installed.



--
Ivan Lazar Miljenovic
[hidden email]
IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Problems with Haskell Platform

Bugzilla from 1@234.cx
In reply to this post by Ivan Lazar Miljenovic
Ivan Lazar Miljenovic wrote:

> Pete Chown <[hidden email]> writes:

>> Is there a way of making Cabal install dependencies using the system
>> package manager, then?

> If you mean cabal-install, then no, there's no integration on either
> side.

That's what I thought.  As a result of this, you may find that you end
up creating private builds of packages which are shipped by your
distribution.  You ask Cabal to install a package, which is not shipped
by your distribution.  Cabal will then build that package's
dependencies, *even if* those dependencies should really be installed
using your distribution's package manager.

> This is exactly the same with C programs.

Yes and no.  If I download the source of a C library and build my own
shared libraries, my programs might not work on machines where the
distribution's version of that library is in use.  The particular
problem in the Haskell world, though, is that Cabal will create this
situation by default.

>> (I believe current versions of ghc insist on linking entirely
>> dynamically or entirely statically.  This makes the situation worse,
>> because the lack of a shared library for X prevents the use of shared
>> libraries for anything else.)

> No, 6.12 defaults to statically but allows dynamic linking as well.

That's not what I meant.  What I meant is that you can't link against
some Haskell libraries statically, and some dynamically.  When linking C
this isn't a problem.  If you don't have a shared version of a
particular library, gcc will pick the static version instead.  You can
even choose static or dynamic for each individual library:

$ gcc foo.c -o foo -lz
$ ldd foo
         linux-gate.so.1 =>  (0x00d0b000)
         libz.so.1 => /lib/libz.so.1 (0x00dd5000)
         libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00152000)
         /lib/ld-linux.so.2 (0x00a69000)
$ gcc foo.c -o foo -Wl,-Bstatic -lz -Wl,-Bdynamic
$ ldd foo
         linux-gate.so.1 =>  (0x00918000)
         libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00db0000)
         /lib/ld-linux.so.2 (0x002e5000)

> Really?  For C, Gentoo ships very few which either default or have the
> option of static libraries, and I assume the same is true for binary
> distributions.

Sorry I misunderstood what you were saying; you're right.  I'm not
familiar with Gentoo, but on Ubuntu virtually everything defaults to
shared libraries.  You can choose static if you really want it, though,
as in the example above.

Pete

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Problems with Haskell Platform

Jens Petersen-3
In reply to this post by Bugzilla from 1@234.cx
On 31 May 2010 20:14, Pete Chown <[hidden email]> wrote:
> I was just thinking, interactions between Cabal and the distribution package
> manager could get worse, as shared Haskell libraries become more common.
>  Suppose a distribution ships a package 'foo', but not a package 'bar' which
> depends on it.  The 'foo' package includes shared libraries.  The user now
> installs 'bar' using Cabal.  This causes Cabal to install 'foo' (because it
> is a dependency) and it won't use the distribution's package manager.

This is a good valid point and one I have been worrying about myself sometimes.

I often find myself hitting Ctrl-C at "cabal install HACKAGE" to run
"yum install ghc-DEPENDENCY-devel"
and before returning to run "cabal install" again.

It would be nice to automate this in some way - cabal-install plugins, anyone??

Jens
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Problems with Haskell Platform

Ivan Lazar Miljenovic
On 4 June 2010 10:27, Jens Petersen <[hidden email]> wrote:

> On 31 May 2010 20:14, Pete Chown <[hidden email]> wrote:
>> I was just thinking, interactions between Cabal and the distribution package
>> manager could get worse, as shared Haskell libraries become more common.
>>  Suppose a distribution ships a package 'foo', but not a package 'bar' which
>> depends on it.  The 'foo' package includes shared libraries.  The user now
>> installs 'bar' using Cabal.  This causes Cabal to install 'foo' (because it
>> is a dependency) and it won't use the distribution's package manager.
>
> This is a good valid point and one I have been worrying about myself sometimes.
>
> I often find myself hitting Ctrl-C at "cabal install HACKAGE" to run
> "yum install ghc-DEPENDENCY-devel"
> and before returning to run "cabal install" again.
>
> It would be nice to automate this in some way - cabal-install plugins, anyone??

How difficult is it just to create an RPM for yourself and then put it
up in some repository for other people to use?

I never use cabal-install to install packages at home (with the
exception of testing versions of libraries I'm writing as I'm writing
them); instead I create a new ebuild for whatever I want and then put
that in the Haskell overlay for Gentoo.

--
Ivan Lazar Miljenovic
[hidden email]
IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Problems with Haskell Platform

Brandon S Allbery KF8NH
In reply to this post by Jens Petersen-3
On Jun 3, 2010, at 20:27 , Jens Petersen wrote:
> I often find myself hitting Ctrl-C at "cabal install HACKAGE" to run
> "yum install ghc-DEPENDENCY-devel"
> and before returning to run "cabal install" again.
>
> It would be nice to automate this in some way - cabal-install  
> plugins, anyone??


Supposedly a future Cabal extension will be to, instead of installing,  
write out a package for a vendor packaging system (yum, apt, yast,  
what have you).  Consider contributing to that effort.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

PGP.sig (202 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Problems with Haskell Platform

Don Stewart-2
allbery:

> On Jun 3, 2010, at 20:27 , Jens Petersen wrote:
>> I often find myself hitting Ctrl-C at "cabal install HACKAGE" to run
>> "yum install ghc-DEPENDENCY-devel"
>> and before returning to run "cabal install" again.
>>
>> It would be nice to automate this in some way - cabal-install plugins,
>> anyone??
>
>
> Supposedly a future Cabal extension will be to, instead of installing,  
> write out a package for a vendor packaging system (yum, apt, yast, what
> have you).  Consider contributing to that effort.
>

However, we have tools for some distros that do this, and some distro
tools support it directly (e.g. "bauerbill --hackage" on Arch Linux
knows how to ask cabal2arch to translate the .cabal file).

Contribut to yum to allow pulling from hackage, by calling cabal2yum?

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Problems with Haskell Platform

Ivan Lazar Miljenovic
Don Stewart <[hidden email]> writes:

> allbery:
>> Supposedly a future Cabal extension will be to, instead of installing,  
>> write out a package for a vendor packaging system (yum, apt, yast, what
>> have you).  Consider contributing to that effort.
>>
>
> However, we have tools for some distros that do this, and some distro
> tools support it directly (e.g. "bauerbill --hackage" on Arch Linux
> knows how to ask cabal2arch to translate the .cabal file).
>
> Contribut to yum to allow pulling from hackage, by calling cabal2yum?

In general, I think this is a bad idea.

I don't know how it is in Arch, but for Gentoo we need to do a lot of
QA'ing to make sure our ebuilds generated with hackport work properly
(which is one reason why we don't churn ebuilds out as fast as you
generate PKBUILDs).  Part of the problem is probably that hackport isn't
as polished as cabal2arch, but a few other concerns we need to take care
of are:

1) Gentoo has categories for packages; whilst for Haskell stuff we can
   usually correctly guess dev-haskell/ as the category, there are a few
   exceptions (e.g. pandoc is in app-text/).  This is an even bigger
   problem when dealing with C deps, etc.

2) Dealing with flags: in most cases, we expose the Cabal flags as USE
   flags, so we need to take care of getting all those dependencies
   right.

3) Multiple versions: we have to take care of supporting multiple
   versions of GHC, as well as different versions of QuickCheck, etc.
   It doesn't help that due to the limitations of portage, Gentoo
   ebuilds do not support proper ranged dependencies.  However, this is
   most probably not an issue for most distributions where users get
   given one version of a specific package and they'll shut up and
   accept it.

4) It has to build always: related to the above, because we don't
   provide binaries, we have to ensure that packages are built reliably
   in a multitude of situations.  We recently had the situation where
   for some reason GHC 6.12.2 would build for someone but then wouldn't
   actually run; we eventually tracked down the problem to his usage of
   ccache: as of 6.12.2, the GHC wrapper script hardcodes which C
   compiler it was built with, and as ccache was only used when building
   packages the path to the C compiler in the GHC wrapper script was
   incorrect (so all our hacks to get this new "feature" of GHC working
   properly when users bootstrap had to be scrapped as they made the
   situation even worse in this case).

Again, these situations are mainly Gentoo-specific due to the unique
nature of the distribution (though distributions without categories
still have to ensure the Cabal-package-name-to-distribution-package-name
mapping is consistent and correct).  I would, however, imagine that in
general having end users use their package manager attempt to
automagically integrate Hackage packages into system packages would be
fraught with peril.

--
Ivan Lazar Miljenovic
[hidden email]
IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Problems with Haskell Platform

Don Stewart-2
ivan.miljenovic:

> Don Stewart <[hidden email]> writes:
>
> > allbery:
> >> Supposedly a future Cabal extension will be to, instead of installing,  
> >> write out a package for a vendor packaging system (yum, apt, yast, what
> >> have you).  Consider contributing to that effort.
> >>
> >
> > However, we have tools for some distros that do this, and some distro
> > tools support it directly (e.g. "bauerbill --hackage" on Arch Linux
> > knows how to ask cabal2arch to translate the .cabal file).
> >
> > Contribut to yum to allow pulling from hackage, by calling cabal2yum?
>
> In general, I think this is a bad idea.
>
> I don't know how it is in Arch, but for Gentoo we need to do a lot of
> QA'ing to make sure our ebuilds generated with hackport work properly

The ones on Arch "just work". I wonder what we're doing differently.
cabal2arch knows a *lot* about Arch's package system.

> (which is one reason why we don't churn ebuilds out as fast as you
> generate PKBUILDs).  Part of the problem is probably that hackport isn't
> as polished as cabal2arch, but a few other concerns we need to take care
> of are:
>

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Problems with Haskell Platform

Brandon S Allbery KF8NH
In reply to this post by Ivan Lazar Miljenovic
On Jun 4, 2010, at 06:54 , Ivan Lazar Miljenovic wrote:

> Don Stewart <[hidden email]> writes:
>> However, we have tools for some distros that do this, and some distro
>> tools support it directly (e.g. "bauerbill --hackage" on Arch Linux
>> knows how to ask cabal2arch to translate the .cabal file).
>>
>> Contribut to yum to allow pulling from hackage, by calling cabal2yum?
>
> I don't know how it is in Arch, but for Gentoo we need to do a lot of
> QA'ing to make sure our ebuilds generated with hackport work properly
> (which is one reason why we don't churn ebuilds out as fast as you
> generate PKBUILDs).  Part of the problem is probably that hackport  
> isn't
> as polished as cabal2arch, but a few other concerns we need to take  
> care
> of are:

I don't think anyone just does a conversion and bodges it into the  
package system, regardless of distribution, package system, or  
conversion tool.  (Or language; you don't do it with gems, eggs, or  
CPAN packages either.)  The tool does the boring part of the job for  
you, but of course you want to edit metadata, test, etc. before  
setting it loose.  Release engineering is not optional.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

PGP.sig (202 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Problems with Haskell Platform

Don Stewart-2
allbery:

> On Jun 4, 2010, at 06:54 , Ivan Lazar Miljenovic wrote:
>> Don Stewart <[hidden email]> writes:
>>> However, we have tools for some distros that do this, and some distro
>>> tools support it directly (e.g. "bauerbill --hackage" on Arch Linux
>>> knows how to ask cabal2arch to translate the .cabal file).
>>>
>>> Contribut to yum to allow pulling from hackage, by calling cabal2yum?
>>
>> I don't know how it is in Arch, but for Gentoo we need to do a lot of
>> QA'ing to make sure our ebuilds generated with hackport work properly
>> (which is one reason why we don't churn ebuilds out as fast as you
>> generate PKBUILDs).  Part of the problem is probably that hackport  
>> isn't
>> as polished as cabal2arch, but a few other concerns we need to take  
>> care
>> of are:
>
>
> I don't think anyone just does a conversion and bodges it into the  
> package system, regardless of distribution, package system, or  
> conversion tool.  (Or language; you don't do it with gems, eggs, or CPAN
> packages either.)  The tool does the boring part of the job for you, but
> of course you want to edit metadata, test, etc. before setting it loose.  
> Release engineering is not optional.
>

Build/does not build? That can be automated.

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Problems with Haskell Platform

Brandon S Allbery KF8NH
On Jun 4, 2010, at 23:04 , Don Stewart wrote:
> Build/does not build? That can be automated.


Automated converters have a certain tendency to become confused and  
put files in unexpected places, etc.  Usually this has less to do with  
the source than the destination; in particular, RPM sometimes makes  
some poor assumptions.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [hidden email]
system administrator [openafs,heimdal,too many hats] [hidden email]
electrical and computer engineering, carnegie mellon university    KF8NH



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

PGP.sig (202 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Problems with Haskell Platform

Don Stewart-2
allbery:

> On Jun 4, 2010, at 23:04 , Don Stewart wrote:
>> Build/does not build? That can be automated.
>
>
> Automated converters have a certain tendency to become confused and put
> files in unexpected places, etc.  Usually this has less to do with the
> source than the destination; in particular, RPM sometimes makes some poor
> assumptions.
>
> --

Sounds like a problem with the converters. cabal2arch does no such thing.
But we tightly control the environment.

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe