> > On my system, 'whereis -b cpp' indicates the location is /usr/bin --- an FHS
> > standard location. Where is that file installed in Arch? Or is the file name
> > changed in Arch? That would be the path to add with the -Y switch.
> 
> In the same spot:
> 
> 22:13 archangel:/dat_e/abs/util-linux> whereis -b cpp
> cpp: /usr/bin/cpp

As /usr/bin is a standard FHS location, I'd like to know where rpcgen is hard-coded to look for the cpp executable. I hope this is not Yet Another WTF example of egghead development.

> ((You really need to install and run at least one partition
> of Arch. Talk about the excitement of trying to iterate down to a final finished
> project the size of TDE when the foundation is constantly changing -- wow!
> It never gets old...))

I don't have that kind of energy. :-) Rolling releases tend to sound like a great idea, but these kinds of problems discourage me from going down that road.

> Seriously, I think there has rarely been any 3 month stretch
> before in recent history where so many of the underlying libraries have had
> significant upstream changes as TDE has tried to dial in a next release -- not to
> mention one with the polish and improvement that TDE has undergone to get to
> the point of this R14 release.
> 
> Little more time on the front end -- better reviews, less
> bugs on the backend :)

I suspect people working with other projects have experienced the same issues. A significant difference is they have more people participating, group knowledge levels are higher and deeper, and therefore they can resolve these bumps faster. Possibly, because those other projects have many more people staying in contact with these upstream groups, I suspect these types of changes get forewarned in one manner or another to those other groups but not to us.

These upstream changes greatly reflect the scratch-your-own-itch mentality. The upstream developers might forewarn everybody of upcoming changes, they might not, but they are going to do whatever they want. Not to mention that the developers who participate in these dependent upstream projects like gcc and glibc are mostly paid programmers working for the big shots in the industry, such as RedHat. They aren't going to wait for people in small projects to voice an opinion.

I think the overall problem is free/libre software changes at a relentless and unforgiving pace. Free source code is just too much to resist for most software geeks, so they tweak, and they tweak, and they tweak.... :-)

Darrell