Callum Lerwick wrote: > The diversity of RPM front ends is a sign we're doing things right. And the fact that none reliably works... > Do we want to drag all of Yum's deps (python, and so on) down in to RPM > itself? How about C++? Since when C code can't do all the stuff Python and C++ can? > 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. You are completely missing the discussion. No one suggested RPM should do prelinking or update GNOME icon cache. The discussion is how to get RPM trigger those. > The GNOME icon cache is a whole other bag of crackrock. Design a better one if you can. > 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. Allowing flexible triggers such that GTK+ can add a trigger to be run whenever an icon is installed belongs in RPM. behdad > http://en.wikipedia.org/wiki/Code_smell > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
