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/
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.
thoughts ?
- KB
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
On 12/03/2010 03:21 PM, Jeff Johnson wrote:> Are you _REALLY_ gonna test -debuginfo packages? How?
no test for any of the debuginfo pkgs, beyond the usual rpm tests ( is a valid pkg and signed with right key etc ).
But I digress ... the suggestion is for a single repository for all -debuginfo instead.
right, that sounds good.
Does anyone have any opinions on this issue w.r.t 6.0 ? Its about time we started looking at the repo layouts and how the yum configs are going to be setup.
- KB
-
Jeff Johnson -
Karanbir Singh