Fedora Project launches Pre-Extras

Jeff Spaleta jspaleta at gmail.com
Fri Dec 17 17:47:44 UTC 2004


On Fri, 17 Dec 2004 12:36:03 -0500, Ken Snider <ksnider at flarn.com> wrote:
> I'm not saying that the above is unnecessary, either - those decisions are
> made for valid reasons, but usually from within the context of *that* repo,
> not from the overall context of the whole, IMHO. There needs to be a way to
> allow repositories to have some sort of meaning - so that Repo A's package
> can't overwrite repo B's package, when said package is part of a larger
> application (example: xmms, xmms-skins, etc), *without* incrementing the
> epoch and subsequently causing *versions* not to matter anymore.
> 
> Maybe a 'release' epoch that doesn't supersede version?

Or maybe... we implement tools that demand signed certs or a signed
tag string to distinquish origin in a programatic way so that package
origin can be uniquely determined.
And once origin can be confirmed, tools learn how to update or fill
deps based on package origin information imbedded in the rpm headers,
choosing packages from the same vendor without the user having to muck
with priorities or pinning.

Or less constrictly, you build tools that understand origin at the
repository level and not at the package level, using signed repository
metadata. This would allow local intranet repositories to be built
that take packages from several locations and put them together as a
collection to feed to internal clients... putting the burden of
compatibility testing not with the packager but at the local intranet
repo maintainer.

-jef




More information about the fedora-test-list mailing list