On Mon, 28 Jun 2010, m.roth@5-cent.us wrote:
R P Herrold wrote:
and this random guessing and recordatation to pollute the RPM database "varies from ** and ** is better than" using a package built from a pre-defined recipe driven by a .spec file, just how?
Well, when it insists on building in /usr/src/redhat,
bzrrrttt --- no such insistance by RPM; just the opposite as it it is fully configurable -- also building as root is a well known and readily avoidable stupidity http://www.owlriver.com/tips/non-root/
to me a week or two ago.... I'd *MUCH* rather have one directory, with everything in it related to whatever I was building, and have *one* place to tell it what it needed to find (such as the above).
Nothing in RPM building practice prevents gathering local collections of packages that relate to one another -- I've published such cluster collections to satisfy dependencies for years and years ftp://ftp.owlriver.com/pub/mirror/ORC/bugzilla/
Right. And the folks who build packages and don't even consider the possibility of looking at a *higher* subrelease of a library (had that a number of times)
Namespace collisions are the responsibility of the craftsman, not the tool, of course; stow and alternatives work perfectly fine if one 'needs' to swap between such in build environments; packages using autotools and 'configure' sensible and richly also readily provide for parallel versioned library installs -- not RPM's job, mon
We won't even begin to talk about python....
The Python community tout weak type checking as acceptible, along with limited namespace disambiguation tools; they lack the interest to follow the convention of holding an API stable across a major version number, and so transfer the burden to their using community. I understand why it seemed like a better choice than say, perl, to Red Hat, but there are some major faults in Python space as well
-- Russ herrold