[arch-dev-public] Files database, potential changes

[Aaron Griffin]

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)[0]
>                    tpkg.write('%NAME%\n')
>                    tpkg.write('-'.join(dirname.split('-')[:-2]))
>                    tpkg.write('\n\n%VERSION%\n')
>                    tpkg.write('-'.join(dirname.split('-')[-2:]))
>                    tpkg.write('\n\n%ARCH%\n')
>                    tpkg.write('i686\n')
>
> 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