New catgets/gencat package

[Charles Wilson]

Igor Pechtchanski wrote:

> I would call this package "libcatgets".  Were you inclined to do it
> "right", you'd probably want to split this into "libcatgets" that contains
> just the runtime DLL, and "libcatgets-devel" that contains the necessary
> headers, the static libs (if any), and the gencat utility.  However, the
> package is probably so small as to not justify such a split.

"smallness" is not the reason for splitting DLLs out of the main 
package.  Coexistence of multiple versions of the same DLL is.

If you don't expect the DLL interface to change in 
backwards-incompatible ways (e.g. you don't expect to bump the "DLL 
number") then don't bother to split the package.  This goes if the 
package is "large" or "small".

Conversely, if you DO think future interface changes are likely, then 
you might as well set things up now so that you're prepared for the 
numbered-dll-packages that will become necessary at that later time. 
And again, that goes regardless of package "size".

> OTOH, since Linux has it as part of the standard C library, why not simply
> submit a patch to newlib that implements those functions?  Use the newlib
> list for this: <newlib at sources dot redhat dot com>.

Geez.

Sometimes I wonder what the purpose of newlib is.  If it is to become a 
full glibc replacement, the why not just use glibc?  Is it a licensing 
thing?

I always *thought* newlib was supposed to be a lean-n-mean, highly 
portable, suitable-for-embedded/limited systems runtime library...but 
maybe I was wrong.

--
Chuck