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