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
