No subject

of RHL from 7.2 to 9?

1) Will this likely cause future dependency problems as rpm evolves on =
the RH side of things?  In other words, if I were to implement your =
recommendation, is there any chance that 6-12 months from now, I'll be =
wondering how I managed to paint myself into a corner?  (Feel free to =
add management-friendly buzzwords.  ;)

2) Assuming that rpm-4.2-1 is The Way To Go, then ideally I would set it =
up on our apt/yum repository locally.  (I suspect that the Better Way =
would be to tweak yum.conf and sources.list to include fedora.us, but =
that doesn't really help us optimize WAN traffic as the number of =
machines which use apt/yum grows.  Hence the local repository.)  Given =
that, I imagine I should create an RPMS.misc directory for these =
one-offs.  Or?  Is there a better approach?

3) I take it that by merely adding the path/repository to yum.conf (and =
to sources.list, for the apt folks), that yum (apt-get) will be able to =
determine that the fedora.us version of rpm is 'preferred', for lack of =
a better term...?  (I think I'm showing my ignorance of the capabilities =
of rpm here.)

4) I suspect more questions are to follow.  If you feel that I'm a =
little weak in my understanding of rpm, could you direct me to an =
appropriate primer?  The RPM approach has shown me that it has strengths =
over, say, Solaris' package manager.  Package management in general is =
preferable to just dropping a tarball into place today, only to resist =
change in the future because, "... we don't know what the upgrade will =
break...."  ;)

jc


> -sv
>=20
>=20
>=20