Xavier, any thoughts? I see a few options:
1. Drop the .tar.xxx stuff completely, and always look for core.db, extra.db, etc. The file extension is really for human use (and unfortunately web server use) only.
2. Have repo-add always produce a symlink like core.db that points to the real database file.
3. The above suggestion- try one extension first, then another, then another. I don't really like this solution as it could result in a lot of unnecessary traffic.
4. Add a new conf file option that can either be global or repo-specific: "DbExt = db.tar.gz" or something.
5. Change the conf file slightly to also accommodate an extension, e.g. [core.db.tar.xz]

> 3. The above suggestion- try one extension first, then another, then another. I don't really like this solution as it could result in a lot of unnecessary traffic.

I do not like it either for the same reason like you. It was just the first naive approach I could think of which does not require config file changes.

Your first suggestion sounds good to me though. The only downside is that you have to specify the compression method on the initial database creation (or use the default).

I think I agree with what xduugu just said.

Since libarchive detects compression format from the header (not from filename), this is already implemented, I guess. ;-)

My vote: 2. (or 1.)

In addition, we should change DBEXT to ".db" asap, and then later we can migrate to any other compression format without pain. Btw, option 2 is the best for migration...

The only drawback of 1 (and/or 2) is the webserver Content-type thing I mentioned. If this doesn't seem like a problem to anyone, I'm go for that.

How would one specify a file format for repo-add to zip the database up if we went with (1)?

Some silly ideas :

case "$REPO_DB_FILE" in
*tar.gz) TAR_OPT="z" ;; -> repo-add -z or ext=tar.gz
*tar.bz2) TAR_OPT="j" ;; -> repo-add -j or ext=tar.bz2
*tar.xz) TAR_OPT="J" ;; -> repo-add -J or ext=tar.xz
*) warning "$(gettext "'%s' does not have a valid archive extension.")" \
"$REPO_DB_FILE" ;;
esac

The main reason I still prefer 2 is that if we just _remove_ repo.db.tar.gz and replace with repo.db, many users will be unable to sync. So for the "migrating" period, we _must_ use symlinks (until we can assume that most users have up-to-date pacman). And imho repo.db -> repo.db.tar.gz is much nicer than repo.db.tar.gz -> repo.db (or duplicated files)...

But in fact, there is no difference between 1 and 2 on pacman side, we use DBEXT=".db " in both cases, so this is just a very minor difference.

@Xavier
> *tar.gz) TAR_OPT="z" ;; -> repo-add -z or ext=tar.gz
> *tar.bz2) TAR_OPT="j" ;; -> repo-add -j or ext=tar.bz2
> *tar.xz) TAR_OPT="J" ;; -> repo-add -J or ext=tar.xz

My first thought was to use some kind of abstraction like your "ext=tar.gz" or in my case "-c{gz,bz2,xz}" but using bsdtar flags directly should be fine, too.

The repo-add command could look like

repo-add [-z|-j|-J] <repo-name> <pkg-file>...

then. The compression part can be made optional when updating a database and repo-add could fall back to a default compression method if none is specified on database creation.

IMO it would be a good idea to jump at the chance and get rid of the database extensions at commandline level in the same sweep. The only thing I am not sure about is how to take the path into account. "repo-add /a/b/c/core" does not make much sense when the file will actually be located at /a/b/c/core.db.


@Nagy
Is it really worth to add backward compatibility to repo-add? This mainly affects arch's official repositories and the only repo which really needs a symlink is core (to be able to update pacman).

I like repo.db symlinked to repo.db.foo

Famous last words... but this looks like something I could code. Assigning to me!