[CentOS-devel] tracking packages in a Release, through the life of the release

Jeff Johnson

n3npq at mac.com
Fri Dec 3 15:21:03 UTC 2010

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.


73 de Jeff

More information about the CentOS-devel mailing list