Re: Haskell in Debian

[Giuliano P Procida]

Hi.

On Wed, May 12, 1999 at 06:21:19PM +0200, Rui Zhu wrote:
> On Wed, May 12, 1999 at 07:00:31PM +0300, Antti-Juhani Kaijanaho wrote:
> > In related note, according to unofficial information from Simon Peyton
> > Jones (the primary author of GHC), the Glasgow Haskell Compiler (GHC) will
> > become free RSN.  Currently GHC has no license.  I've tried to bootstrap
> > it but it is so big a beast that I'll probably let it pass.  I hope
> > someone else packages it when it becomes free. 
> 
> It is good news though it is only unofficial one.  I've tried to build
> 4.02, it took me 4 hours on my K6-233 box and costed more than 100MB
> disk.  I'd like to apply to become a Debian maintainer and package it,
> if no one want to take it.

Well, for about the fifth time over the years, I'm having a go at
compiling ghc (I finally have plenty of disk and a decent amount of RAM).

I've hit two problems so far:

a) happy is unhappy [1]

 I have mailed Simon M? regarding this. Binary is distributed for use
 with libc5, "source" is distributed with a libc5-dependent bootstrap. I
 couldn't compile from the source due to ghc being unhappy with the
 options happy wanted (-fhaskell-1.3) and various hard-codings of the
 ghc path and the ghc version.

 I would happy to take on happy, once it's happy. This may just be a
 case of the GHC people making their latest CVS snapshot available. Oh,
 and there is the small question of the lack of a licence (I also queried
 this).

b) ghc runs out of heap compiling its parser

 The file ParseIface.hs (in ghc/compiler) needs more than 64M but no more
 than 128M of heap to compile. With 64M of RAM and not too much else
 (X and ntpd) running you are looking at 1500+ garbage collections for
 about 1.5G of allocation. This file took 10-20 minutes on my machine.

If you have >64M of RAM you should probably be the maintainer. I'm
thinking of upgrading in the next month of so, funds permitting.

In any case, given the quantity of stuff that makes up ghc (the compiler,
the profiling tools, the parallel simulation package, etc.), some division
of labour might be sensible.

If that turns out to be a bad idea... well, I have an alpha on which
I could _try_ to get ghc up and running, presupposing a diff.gz and a
working bootstrap compiler. I would need to find some more memory for
the poor thing though.

Lastly, the ghc-users list seems to be rather quiet, but I've only just
subscribed.

Giuliano.

[1] note for the bemused: happy is a yacc for Haskell

Re: Haskell in Debian

[Giuliano P Procida]

On Thu, May 13, 1999 at 09:10:48PM +0100, Giuliano P Procida wrote:
> I've hit two problems so far:
> 
> a) happy is unhappy [1]
> b) ghc runs out of heap compiling its parser

Well, I spoke to soon. I have a compile failure with no error message:

../../../ghc/driver/ghc -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O 
-split-objs -odir PrelBase  -H10m  -c PrelBase.lhs -o PrelBase.o -osuf o
make[3]: *** [PrelBase.o] Error 1

and that is as far as I get (make -k doesn't get much more done).

Giuliano.

Re: Haskell in Debian

[Giuliano P Procida]

Hi.

On Thu, May 20, 1999 at 02:00:55AM +0200, Rui Zhu wrote:
> Just FYI, accidently I found at the GHC site that this file can cause
> trouble, there is memory leak.  (see
> )

I know, SPJ got fed up with all the reports so he added a note. You
can also get things to compile with GhcHcOpts += -optCrts-M100m which
just ups the heap limit to 100Mb! But I imagine the solution posted is
probably more sensible.

I have made no progress with GHC compiling, the hsc that's built dies
in fflush (in the supplied binary RTS). I'm considering taking a
binary editor (ah, the memories of svgalib) to that file given that
the call is apparently redundant. So what's NOP in Intel asm? :)

I have posted a bug against libc6, it looks like it may be related to
the IO problems people were having with C++ (null pointer when trying
to call the "sync" method associated with an io stream, in my case).

It may just require a recompile of the RTS. I did try using the built
RTS instead of the supplied one, but it didn't work properly.

Giuliano.

Maintainers and the Database

[Giuliano P Procida]

This mail message started out as a response to Marcus Brinkmann's
comment on the policy list:

> I think that [the multiple maintainer] issue can't be resolved
> properly ("we are stuck") without further input from all the other
> developers not participating on debian-policy.

I'm hardly a participant, but I do read it. This message is now mainly
about the database and only relates partly to the above. The real
questions are, IMO:

a) what is package ownership?

We need to know who put together a package, who to send bugs to and
who ping if the package needs to be updated. We need to know if a
package is orphaned (has no owner).

b) how well is this reflected in current practice (and policy)?
c) what changes are needed to improve the answer to b)?

I'm not touching these!

d) What about a database to handle some of this for us?

This is in progress and is what I ramble on about below (knowing
little about the existing db work).

*The Database*

It is important that the database reflect reality for it to be useful,
both in its design and in its content. This applies to all databases.
This is unexciting, but hopefully obvious.

  The Design

A database of Debian developers (package maintainers plus all those
helping with debian who do not actually emit .debs) is needed and in
preparation. Package ownership details are desired in the database.

Relational Databases 101 says you will need (at least) one relation
for the people and another for the packages. (It would be a bad design
to have an attribute "packages" which listed all their packages).

If each package has an attribute "owner" then there arises the problem
of what to put:

a) When there is no owner (orphaned). Answer: Easy, use NULL.

b) When there are multiple maintainers (maintainer group). Answer: say
   "oh dear", or enter only one of them (arguably incorrect), or
   create a fake maintainer which is actually a group (yuk yuk), or
   try and handle groups directly, in some moderately complicated
   fashion, OR:

If instead there is a separate relation for ownership linking people
and packages, then there is no problem with people having 0, 1 or more
packages or with packages having 0, 1 or more owners. Queries to list
orphaned packages, list a given person's packages, etc. are hardly any
more complicated than with the other design. Moreover, the data (and
schemas) are trivially convertible from the other design to this one.

Summary: it should not be a problem for the database what form of
"multiple maintainership" (if any) is eventually adopted.

* Could someone in the know say whether there is a separate ownership
* table? I am happy to give a hand with PostgreSQL hacking (I am in
* the process of setting up a (pg) db at work - a learning experience
* :-).

  The Content

Developer information should be at the control of the individuals and
I imagine this has been what most of the existing DB work has been on.

Package information is a different matter. One issue is what to do
when a package disappears for good, being deleted from the archive.
The corresponding entry in the database ought to be updated or deleted
to reflect this. Plenty of information can be extracted automatically
as each .deb arrives (including the _packager_ - via the PGP key).

Ownership information is a little more tricky (think NMUs, multiple
maintainer packages and orphaning) but it ought to be possible to
automate this to some extent.

Someone with ambition may want to do something to add summaries of
data in the bugs system.

* I am prepared to help with any of the miscellaneous scripting the
* above involves.

  DB Care

Once a design stabilises the db needs to be looked after in much the
same way that Guy (and helpers) look(s) after the archive. The web (or
whatever) interface is unlikely to be perfect initially and will need
maintainance.

  The "Maintainer:" field

This will probably be rather important in terms of generating data for
the db. It is supposed to be the canonical means of contact between
user and developer in relation to a given package. I know much less
about how this propagated and used by various things (bug db, bug
command, dinstall, dpkg-*). It is something you can mail (i.e., one or
more email addresses).

Whereas packages are nicely identified by their name. The same cannot
be said of developers and the "Maintainer:" field, at the moment. This
is unfortunate. Most email addresses found in the field correspond to
an entry in the PGP key ring and hence to real humans.

There are plenty of (technical) solutions to this problem and the with
luck a wider discussion of the "multiple maintainer" issue will fix
this as a consequence.

Enough rambling,
Giuliano Procida (Myxie)
-- 
mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] | public PGP key ID: 93898735
home: +44 1223 561237 / 547 Newmarket Road, Cambridge CB5 8PA, UK
work: +44 1223 332127 / Magdalene College, Cambridge CB3 0AG, UK
work: +44 1223 335333 / International Studies, Cambridge CB2 1QY, UK

Automatic packages (was Re: "super" pkgs)

[Giuliano P Procida]

Hi.

Some people mentioned last month that it would be nice to have the
automatic removal of automatically selected packages (i.e., packages
selected by dselect or apt in order to satisfy dependencies) as it
would fit in nicely with meta-packages implemented using (otherwise
empty) .debs with dependencies.

The simplest (ha ha) solution I can think of is to add a new state to
the Install/Purge/Remove item. Currently my status file includes:
  Package: libpng0g
  Status: install ok installed
However, I doubt I went looking for this package, some other one must
depend on it. I would suggest that this should read:
  Status: automatic ok installed
instead.

If all pkgs that depend on this are removed then dpkg should removes
it as well (dpkg --remove --pending, or apt all by itself), leaving:
  Status: automatic ok not-installed
or
  Status: automatic ok config-files
when the package has remaining configuration.

So "automatic" would mean either "install" or "deinstall" according to
whether or not a packages dependencies (pre-depends and conflicts?)
are satisfied.

The admin should be able to change package statuses to "a"[utomatic]
(like "+", "-", and "_") at the press of a key within dselect.
However, most changes *into* the "automatic" state would be performed by
dselect (when it brings up the dependency resolution screen) or by apt.

How does this sound? Too much of a change to dpkg? Too much complexity
for the newbie dselector? Not enough benefit? Exactly what test is to
be performed to determine whether "automatic" means "install" or
"deinstall"? Bearing in mind the huge number of packages available
now, wouldn't it be nice to have all lib packages set to automatic?

Of course, it also has to work with chains of dependencies.

Giuliano Procida.

ps It would also annoy people who type: dpkg -l | grep ^ii :-)
-- 
mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] | public PGP key ID: 93898735
home: +44 1223 561237 / 547 Newmarket Road, Cambridge CB5 8PA, UK
work: +44 1223 332127 / Magdalene College, Cambridge CB3 0AG, UK
work: +44 1223 335333 / International Studies, Cambridge CB2 1QY, UK