On Fri, 17 Dec 2004 12:36:03 -0500, Ken Snider <ksnider@xxxxxxxxx> 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