Re: Fedora Project launches Pre-Extras

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]


[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]