On Fri, 17 Dec 2004, Jeff Spaleta wrote: > 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. Please, look at smart: http://dag.wieers.com/packages/smart/ And look at the GUI. -- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]