On Mon, 28 Jun 2010, Les Mikesell wrote: > On 6/28/2010 1:43 PM, R P Herrold wrote: >> >> All RPM needs is for people to read and use the tools, and all >> this is done well presently > > What's the right approach with RPM to have multiple versions of an > application installed simultaneously? stow, alternatives, and versioned namespaces already discussed in my last post on this thread >> "Those who don't understand UNIX are condemned to reinvent it, >> poorly." – Henry Spencer > > Yes, but unix was developed from the beginning with the idea of having > test and production instances installed simultaneously and different > users having their own different local copies of libraries and > executables. It is RPM that doesn't understand those concepts. I started in the commercial Unix world with HP-UX; in Linux with binary TGZ-balls - I recall their approach and HP Depot files. Each are a poor knockoff, compared to the richness of expression possible with RPM (or .deb) RPM understands those concepts well, and supports working with the autotools; it will happily set up, build in, an run test in 'build chroots' populated to taste with various versions > And while you are at it, what's the right approach for using RPMs that > are developed without coordinating their namespaces with all other > potential sources of RPMs. This is a political problem, and not a technical one. LANANA is (properly) will not willing to impose a solution, but rather to assign namespaces without collision; the FHS offers quidance; th LSB is the only 'rosetta stone' interchange point of any mass other than defacto ones build up by vendors and prominent independents Answered the other way: the 'right' approach is to avoid poor packagers and prefer good ones. In self defense, I package to meet my quality needs, pulling liberally from 'good' peers. I see that my archive holds 839 SRPM packages in 350 groups listed that all largely interop [or are obsoleted but left for others who may want them] -- Russ herrold