On Thu, 2008-09-11 at 12:33 +0200, Ralf Corsepius wrote: > I would turn this argument around: rpm missed its opportunities "to do > various things" forcing people to circumvent rpm's limitations by > ruck-sacking rpm with add-ons such as yum, yast/ycl etc. Oh come on. How is layered, loosely coupled, encapsulated separation of concerns NOT good design? The diversity of RPM front ends is a sign we're doing things right. Do we want to drag all of Yum's deps (python, and so on) down in to RPM itself? How about C++? RPM should be kept as small and simple as possible. We should avoid creeping features into it. We need to think carefully about what RPM's job really is. If anything it needs to be simpler. There was talk of ripping the URL-download "feature" out of RPM. Did that ever actually happen? Two things are getting completely confounded in this thread. 1) Prelinking 2) GNOME icon cache Prelinking is a non-vital system-wide optimization. It does not need to be in RPM. The GNOME icon cache is a whole other bag of crackrock. Is it really required for system functioning? I'm assuming since we're bending over backward for it, it is required. Duplicate spec scriptlets stink, but I think the real problem is in GNOME. Should the cache really be system wide? Why is it not per-user, and automatically re-generated? The whole thing stinks of bad design, we shouldn't have to be special-casing crap like this in our package management in the first place. It doesn't belong in RPM *or* yum. http://en.wikipedia.org/wiki/Code_smell
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
