On Dec 3, 2010, at 10:07 AM, Karanbir Singh wrote: > hi, > > one thing that I'd like to do with 5.6 and 6.0 is to have centos-release > carry repo info for the debuginfo and the vault repo's for the same > Release. For 6.0 it would be fairly slim to start with but for 5.6 it > could look like this : > > Enabled by default: > > [base] > [updates] > > Available, but not enabled: > [5.5] > [5.5-updates] > > [5.4] > [5.4-updates] > > .. > > [5.0] > [5.0-updates] > > Allowing people to get specific packages from anywhere in the Release's > past. the baseurl for these will point at vault.centos.org/ > Various user-oriented tags like "updates" or "testing" which reflect distribution policies start to become fetishistic ritual when applied to -debuginfo. Sure parallel structures to paths and predictable rules make sense, but so does a KISS approach Put all the -debuginfo packages in one directory. The reason for a different approach to -debuginfo distribution is that "upgrade" and "testing" (for -debuginfo) simply make no sense. Are you _REALLY_ gonna test -debuginfo packages? How? And "upgrade' for -debuginfo is a bit different too: you still may need the -debuginfo installed until every package that might use that -debuginfo is upgraded. And that isn't (and I'd argue cannot, adding deps to -debuginfo packging isn't the right approach imho). But I digress ... the suggestion is for a single repository for all -debuginfo instead. > Similarly would be the debuginfo .repo's. For /5/ we have a single > debuginfo repo, for /6/ we can, and i think we should, split these up > into repo's that match the release's. so 6.0's debugs end up in > debuginfo.c.o/6.0/ and 6.1 goto d.c.o/6.1/ etc. Just as with the older > release's .repo files - these would be present but disabled. Also, I'm > trying to plumb in debuginfo signing. But it might end up being a > different key to the main distro signing key[1], cross signed by the > distro key and master keys. lets see how that pans out. > Ick, but whatever re signing rituals. Note that a better crypto framework for *.rpm, not additional "policies" regarding who/what/where is permitted to sign -debuginfo, is needed. Again, I digress, but can likely help with the plumbing automation even for @rpm.org code if interested. hth 73 de Jeff