On Thu, Dec 29, 2005 at 03:28:34PM -0500, Jeff Spaleta wrote: > I think protectbase by default is a particularly bad idea for a > number of reasons. But if i understand the original poster > correctly, the problem he wants solved is a way to easily update > packages in a way that recognizes from where installed packages were > originally installed from after selectively install packages from a > number of different vendors. I don't see a good solution to this > problem since the rpmdb doesn't keep track of this sort of > information. The closest thing that can be used to aid this sort of > update is gpg signatures. I agree, this is a different problem at all. But even then I would reconsider. Assume package foo exiting at ATrpms at FC<N> time, and then it makes it into FC<N+1> core. You wouldn't want to exclude the upgrade path to another repo. Also some packages may be dropped by FC like pine was, and it may reappear in another repo. Again, you'd like to have upgrade paths not accidentially broken due to vendor/origin lock mechanisms. I think these idioms are trying to cure something at the wrong end. I'd ask the following: o What needs to be fixed? o Is it really broken (how many reports have there been on this causing a real issue)? o Can't it be fixed at the root instead of juggling with preferences, weighing, scoring, repo/disto/origin locking and the same? That's certainly something many people see differently and that must be taken into account. There are also different roles. The sysadmin guy will need a stable repo which guarantees non-breakage (and he will probably not use FC but RHEL and clones, but anyway). The desktop homeuser guy will be more open to less tested packages and more functionality and so on. I think this is best served in a stability graded repo. E.g. ATrpms has stable, testing and bleeding (it used to have 5 classifications!), kde-redhat has similar staging, and most other repos have a two classed stability categorization by now. Using these stability grading makes it easy to have fast QA on packages (they enter bleeding, get promoted to testing and later stable, similar to rawhide -> updates-testing -> updates QA, only that it happens on the same distribution level) -- Axel.Thimm at ATrpms.net
Attachment:
pgpiNE9C8RA2w.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
