On Thu, Feb 11, 2010 at 9:53 PM, Dan McGee <[email protected]> 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
