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.