My periodic bark at auto "tools" 2003/1 edition (was Re:rtems-ss-20030128)

[Ralf Corsepius]

Am Mon, 2003-02-03 um 16.15 schrieb Thomas Doerfler:
> Hello,
> 
> ... many lines snipped...
> 
> > > 
> > > * Rebuild the rpms from source and edit the rpm.specs on your demands.
> > > (This typically means to change the package names and the prefix - and
> > > to read the manual of another tool: rpm)
> > 
> > We have considered building release tools to install into a separate
> > $prefix from snapshots.  Something like /opt/rtems-4.6 instead of
> > /opt/rtems.  This doesn't solve your immediate problem but distinguishes
> > release branch tools from development branch ones.
> 
> years ago there was
Here, you say it "was". It simply doesn't work!

>  an aproach of installing a given toolset 
> (gcc/binutils/newlib/etc...) to something like
> 
> /opt/rtems/gcc-2.95.2-binutils-2.8-newlib-x.y
> 
> Whenever you wanted to work with a given project and RTEMS 
> snapshot, the only thing to do was to include the 
> corresponding path into your PATH environment. I really like 
> this way of tool installation, because then each user can 
> select, which toolset is to be used for his project. This is 
> more or less the only way I know to install various toolset 
> versions on one machine.
>
> 
> Unfortunately the standard RPMs now come without that 
> installation prefix, I never quite made out why.
Quite simple, this form of "canonicalization" is subject to the
"Symbol-Grounding-Problem", as AI calls it.

It tries to apply a classification into certain categories.
At the beginning such attempts look promising, but at some point later,
somebody will be asking for addition or removal of a new category. 

Very soon you'll end up with
"gcc-2.95.2-binutils-2.13-withoutpthreads-noi18n-nomp-womenonly"

As such tuples actually span a multidimensional matrix, you'll very soon
get lost in "vector space".

Side effect: You won't be able to upgrade on of the components you are
using, even if this component would be compatible (eg. you would not be
able to upgrade to binutils-2.14, even if they were compatible).

> Wouldn't it solve many problems to go back to that LONG 
> installation prefix in the standard RPMs?

I think we should go the way Joel brought up.

Ralf