[arch-haskell] Layout of ABS tree for Haskell packages?

[Xyne]

> > Magnus> I've just downloaded all 1937 packages maintained by
> > Magnus> arch-haskell on AUR, and I'm about to put them all in a git
> > Magnus> repository.  Before doing that I thought I'd ask if anyone has
> > Magnus> suggestions on the directory hierarchy in that repo?
> >
> > What do you think about mimic the Hackage hierarchy?
> 
> It wouldn't be possible to mimic it completely since hackage allows
> several categories for a single package.  However, the packages in AUR
> all have a single category (even though I'm not sure how they get
> them), maybe we could use that.

I would ignore the AUR categories completely in the git repo.  Those categories
are largely ignored by Arch and may be removed later. Also, as the ABS and
binary repos will be separate from the AUR, I see no reason to use those
categories.


> > Magnus> The only criterion I can think of is that we'd probably would
> > Magnus> want binary and source packages separated in some way.
> >
> > I agree with that. Binaries could go all in one bin directory (there
> > is no binary category in Hackage ;) )

I don't see the point of making such a distinction in the git repo. Whether the
package is distributed in binary or source form has no effect on the PKGBUILD
and local source files. I think the git repo should be agnostic of what is done
with the packages downstream.

To maintain the binary repo we will need to create some tools. Those tools can
use a separate list of packages to determine what to build. Changing that list
will therefore not alter the hierarchy in the git repo.

Categorization can be added to some interface for accessing the PKGBUILDs
(e.g. on Hackage, archlinux.org or elsewhere). That would enable packages to
follow the same categorization that Hackage uses, including multiple categories
for a single package. It would also be more homogeneous and intuitive,
preventing confusion when using both hackage and our ABS system.

Basically, I think we should keep everything modular as far as possible.

I should also clarify that when I suggested an ABS system, I simply meant a way
to provide PKGBUILDs and local source files for the end user as they currently
obtain from the AUR. I didn't not mean that we should mimic all aspects of the
Arch ABS system and "abs" package. I think it would be simple enough to have a
single base directory of all the current PKGBUILDs and local source files on a
server, e.g. current/foo/, current/bar/. They could be easily categorized with
a second directory using symlinks, e.g. /categories/network/foo/
--> /current/foo/. A script would create such symlinks based on what is present
in the directory and the current categorization on Hackage.





Other thoughts:
* The translation table of Hackage names to Arch names (currently hardcoded
  into cabal2arch) should be easily accessible programmatically for use in
  scripts and other tools (e.g. bauerbill).

  In general, all metadata should be programmatically accessible to support and
  encourage the building of tools for working with packages.