[CentOS-devel] tracking packages in a Release, through the life of the release
n3npq at mac.com
Fri Dec 3 10:21:03 EST 2010
On Dec 3, 2010, at 10:07 AM, Karanbir Singh wrote:
> 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:
> Available, but not enabled:
> 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, 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