[arch-dev-public] Files database, potential changes
aaronmgriffin at gmail.com
Fri Feb 12 12:10:42 EST 2010
On Thu, Feb 11, 2010 at 9:53 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> So right now we have our create-filelists cronjob in the dbscripts
> pumping out files databases. This is great, except that the file is a
> lot less useful to automated processes than you would think. If you
> hadn't guessed yet, I'm trying to get this stuff back in the website.
> I have it working about 90% locally but the last 10% is the key.
> The problem stems from our old single-arch, no-any packages mentality.
> The files DB simply doesn't have enough information to match up a
> *complete* package specification with its files due to these busted
> assumptions. Although we can parse the pkgname and pkgver from the
> directory names in the zip, we have no idea what is an 'any' package
> and what is an arch-specific package. Since every package is unique on
> the tuple of (pkgname, repo, arch), we are missing one of the three
> components here in this database.
> One thought is to actually implement the hack into create-filelists as
> I currently do when parsing the files DB:
> if type == 'files' and fname == 'files':
> # we don't have desc to provide us with name/version here,
> # so we need to do some of the work on our own.
> dirname = os.path.split(tarinfo.name)
> These are the required attributes to get a full package spec. Does
> anyone object to placing a desc file inside the files database holding
> this information to make it easier for tools to work with our
> multi-architecture ecosystem these days? Or if you have a better idea
> than the above, I would of course be up for that as well.
Sounds good to me - the size increase will be negligible compared to
the files DBs themselves, and existing things that parse the 'files'
files will still work as-is
More information about the arch-dev-public