On Tue, Oct 12, 2010 at 11:41, Gour D. wrote:

On Tue, 12 Oct 2010 10:42:50 +0100

...

...

...

...

...

> "Magnus" == Magnus Therning wrote:

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.

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 ;) )

So maybe something like this? habs/ bin/ lib/ / / ... system/ <package k>/ / ... aur lib/ <package m>/ / ... system/ <package n>/ / ...

Magnus> Any thought or comments on this.  I'm particularly interested in Magnus> comments from people who have experience with working with the Magnus> ABS-related tools.

I don't have that, but when I was using Gentoo, its overlays were structured in a similar way.

Oh, don't worry about that comment of mine, *all* suggestions are welcome. My knowledge of the ABS tools is *very* limited, so I don't want to inadvertently come up with something that forces us to do a lot more tool development that we want to. /M -- Magnus Therning                        (OpenPGP: 0xAB4DFBA4) magnus＠therning．org          Jabber: magnus＠therning．org http://therning.org/magnus         identi.ca|twitter: magthe

On Tue, Oct 12, 2010 at 12:05, Thomas Girod wrote:

Hi there. Small question: are you planning on having the binary packages inside the git repository ? If so, why ?

No! /M -- Magnus Therning                        (OpenPGP: 0xAB4DFBA4) magnus＠therning．org          Jabber: magnus＠therning．org http://therning.org/magnus         identi.ca|twitter: magthe

On Tue, Oct 12, 2010 at 12:52, Gour D. wrote:

On Tue, 12 Oct 2010 11:50:46 +0100

...

...

...

...

...

> "Magnus" == Magnus Therning wrote:

Magnus> It wouldn't be possible to mimic it completely since hackage Magnus> allows several categories for a single package.  However, the Magnus> packages in AUR all have a single category (even though I'm not Magnus> sure how they get them), maybe we could use that.

Well, we could choose one 'main' category in that case.

Otoh, granularity of categories in Arch/AUR is quite rough...mostly all the haskell packages are 'lib' or 'devel' and that's why I thought about some finer classification.

I'm not sure I understand what you mean here. Would you mind giving an example? /M -- Magnus Therning                        (OpenPGP: 0xAB4DFBA4) magnus＠therning．org          Jabber: magnus＠therning．org http://therning.org/magnus         identi.ca|twitter: magthe

On Tue, Oct 12, 2010 at 14:59, Gour D. wrote:

On Tue, 12 Oct 2010 13:11:03 +0100

...

...

...

...

...

> "Magnus" == Magnus Therning wrote:

Magnus> I'm not sure I understand what you mean here.  Would you mind Magnus> giving an example?

Well, it would be nice and (maybe) easier to find some package if e.g hdbc-sqlite3 would be under 'database' category instead of just 'lib'.

However, the problem is that if you browse categories available on AUR, there is none labelled as 'database' 'cause there 18 categories only including some very general like {gnome,kde,xfce,..}.

Ah, then I understand. And I disagree :-) To me this is an issue of discoverability of packages, I just don't think the ABS repo is the place to solve that issue. We'll need a tool to support our ABS repo, so that users can search for packages the same way they now can search AUR. /M -- Magnus Therning                        (OpenPGP: 0xAB4DFBA4) magnus＠therning．org          Jabber: magnus＠therning．org http://therning.org/magnus         identi.ca|twitter: magthe

...

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.

On 2010/10/12 Xyne wrote:

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.

I filed a pull request to support this feature (if we are thinking of the same thing). The plain text translation table is here : http://github.com/remyoudompheng/archhaskell/blob/master/data/library-provid... -- Rémy.