[arch-dev-public] Rewriting dbscripts (packagers should read this!)

Florian Pritz bluewind at xinu.at
Mon Sep 30 13:36:18 EDT 2013


After having read the recent git thread I've come to the conclusion that
we should rework dbscripts before we start working on the package
backend (although my proposal works better with git because it uses tags).

TLDR: You should care and read it. If you don't I won't care if you
later miss features that contradicts my proposal.

Note: The text below is more or less a cleaned up brain dump so it's
probably not complete and possibly confusing. If so, please tell me. I'm
also open for discussion via irc as long as the important points are
later sent to the ML.

# Goal
Decouple dbscripts from svn to make it faster and simpler. Moving lots
of packages is awefully slow right now.

svn tracks the PKGBUILDS and tags refering to certain PKGBUILDs.
dbscripts maintains an internal, separate database which tracks in which
repo a given package is (identified by a pkgname and a tag).

# Definitions
- tag: Identifier for a particular pkgbuild + support files;
  git tag/svn repos subdir; "$epoch:$pkgver-$pkgrel"
- package: A single .pkg.tar.xz file. -debug and split packages
  count as single packages.

# dbscripts DB

This is not important to packagers, it's internal to dbscripts and only
tracks which packages are in a given repo for history purposes.

The db contains files called "$repo/$arch/$pkgname" which contain <<EOF


The whole tree will be versioned via git.

This is just my idea,
<https://wiki.archlinux.org/index.php/User:Pierre/pkgdbgit> might be
talking about simply extracting the db repo-add creates for pacman and
tracking that in git, I don't know.

I believe dbscripts wouldn't need a db to perform the functions outlined
below so we can talk about this later.

# Executables
Note: Since releasing/moving/removing to/from any (the arch) doesn't
      make sense any will be an alias that targets all repos.
      "db-remove extra any pkg1" will therefore remove pkg1 from
      i686 and x86_64, similar for "commitpkg -a any ..." which
      will release to i686 and x86_64.

## commitpkg [-a $arch] (from devtools)
 - create a tag and upload packages to the server
 - -any packages default to be released to all arches
 - if target arch is supplied we only release to one arch (also counts
   for -any packages)
 - do we want support for directly supplying the commit message?
   (commitpkg "update to version 1.2.3")

## commitpkg [-a $arch] pkg1.tar.xz pkg2.tar.xz
 - if called with arguments it will only release those, nothing else
 - -any packages will be release to all arches unless -a is used

## db-add $repo $arch pkg1.pkg.tar pkg2.pkg.tar
 - check if the tag exists in the package repo (extract pkgbase from
 - check if the user has permission to release to the repo
 - call repo-add on the package

## db-update
 - call db-add for every package in the user's staging directory

## db-move $srcrepo $dstrepo $arch pkg1 pkg2
- move packages between repos

## db-remove $repo $arch pkg1 pkg2
- call repo-remove

# Example
pacman, core repo
pacman-debug (automatic debug split), core repo
pacman-shared (split any arch package), core repo
pacman-contrib (normal split), extra repo

All these are create by building a single PKGBUILD.

db-* scripts still run on the server, but simplicity I'll ignore that below

## Releasing
Note: Just create a ./release script in your package repo to do that if
a simple foopkg doesn't cut it.
 - corepkg pacman-xxx.pkg.tar.xz pacman-debug-xxx.tar.xz
 - extrapkg pacman-contrib-xxx.tar.xz
 - db-update

## Removing
 - db-remove core any pacman pacman-shared pacman-contrib pacman-debug
   - removes the packages from both arches

## moving from testing to core:
 - db-move testing core i686 pacman pacman-shared pacman-contrib
   - moves only i686, leaves x86_64
   - to move both arches at once just use any instead of i686

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20130930/2cf129fa/attachment.asc>

More information about the arch-dev-public mailing list