Boot speedup with readahead

[Callum Lerwick]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20080915/4bab9ee6/attachment.bin