repoman: manage repos like packages (post your repo data here)

Xyne · 2013-04-08 03:45:14

Project Page

http://xyne.archlinux.ca/projects/repoman/

About

I have had this idea kicking around in my head for ages. I made an feeble attempt at it a long time ago with "reposearch" or whatever I called it, but that was another dust-collector that I eventually abandoned.

The idea is simple: manage repos the way pacman manages databases.

Repos are specified with a metadata file in JSON format. These files are collected into a single JSON file that acts as a database. These database files can be retrieved from servers specified in a local file. The user can then query all of the repos and enable whichever ones he wants.

It is also possible to query all known repos for a given package. This can be very useful when choosing what to enable.

Output Example

############################# Generated by Repoman ############################
[core]
# Official Arch Linux core repository.
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist

[extra]
# Official Arch Linux extra repository.
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist

[xyne-x86_64]
# A repo for Xyne's own projects: http://xyne.archlinux.ca/projects/
# Packages for the "x86_64." architecture.
# Note that this includes all packages in [xyne-any]
SigLevel = Required
Server = http://xyne.archlinux.ca/repos/xyne

[community]
# Official Arch Linux community repository.
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist

[multilib]
# Official Arch Linux multilib repository.
# 32-bit applications for x86_64 systems.
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist

###############################################################################

Submitting Repos and Servers

The project page is the best place to get up-to-date information about file formats, etc. Among other things, it includes an example repo metadata file that you can use as a template to submit your own repos for inclusion. The source archive contains more.

You can also submit URLs if you would like to maintain your own repo metadata database similar to the one on my site.

So far I have included "core", "extra", "community", "multilib", my own repos, and "haskell". I would like to include all of the official repos ("testing", etc.) and probably all of the repos unofficial user repos listed here, but I am not going to create all of those files on my own. If you are interested in this, help out and show me that it's worth maintaining.

Caveats

This is a first draft from a single coding session. Options may change in the near future. It has not been fully tested yet either, so make sure you check the output before using it in pacman.conf.

I will probably split the metadata database on my site into three separate databases too: one for the official repos, one for my own repos, and one for collected repos.

Please post questions, comments, feedback, metadata files and crackers in this thread.

progandy · 2013-04-08 04:24:13

That is really nice, I'll consider using it.
I have some ideas for new features as well:
- Print list of enabled repositories in current order
- interactive mode for enable (choose position with select)
- each repository should have a field for suggestions for its placement in the repository order. (no automatic selection, purely informative. Maybe a "verbose description"?)

Last edited by progandy (2013-04-08 04:28:01)

Xyne · 2013-04-08 16:17:20

1) I suppose I could do that, but essentially that is what the output already is.
2) I am considering using some of the ncurses code from serman (serman2) to do that.
3) At first I had included "before" and "after" fields in the metadata file, but it felt a bit cluttered and I realized that respecting those field might lead to unintended results. As it is now, I think it belongs in the description field.

I may just add an "edit" mode to open a text editor (using the EDITOR environment variable) with the current list. It is also possible to edit the "enabled.json" file directly, so I'm not sure that an interactive mode is worth the additional code complexity.

I'll wait to see what others think. I don't need the feature myself and it would feel like a waste of time to implement it if almost nobody will ever use it.

The most important thing right now is to find some contributors (hopefully the repo maintainers themselves) to submit metadata.

progandy · 2013-04-09 17:31:17

I have metadata for the testing repositories:
https://www.dropbox.com/sh/x2h7st3bqoqeukj/gHEms1KjAH

Xyne · 2013-04-10 18:19:05

Thanks. The updated files are uploading as I type.

I have left "docurl" for now. At first I wasn't sure it if was "doc url" or "do curl". I will probably change it to "info page" (no reason to avoid spaces). I'll wait to see what other needs pop up before finalizing the metadata fields. I hope to keep them as few and simple as possible, but source websites, authors, signatures etc. may be useful.

fukawi2 · 2013-07-03 02:21:17

How's this for metadata (I think)?

{
  "description": "Automated (untested) binary builds of the AUR.",
  "architectures" : [
    "i686",
    "x86_64"
  ],
  "dependencies" : [
    "core",
    "extra",
    "community",
  ],
  "options" : {
    "SigLevel" : "Never"
  },
  "locations": [
    "Server = http://aurbin.net/$arch"
  ]
}

Arch Linux

#1 2013-04-08 03:45:14