> Charles,
> Would this be acceptable?
>
> bin/packages + /glibc-2.0
> |
> + /glibc-2.1
> |
> + /glibc-any
I guess so, but I sort of got the idea (perhaps incorrect) that there were
packages that *did not* require a C library. If that's the case, the above
is misleading (to me it implies the package requires a c library, but
doesn't care which one). Something like + /glibc-none or maybe + /static
would indicate packages with no libc requirements.
My list of a few of the proposed CVS directory names, and what I would
*assume* was contained within, based on the directory name:
+ /glibc-any
would indicate packages work with any libc version...there's probably
nothing that could correctly go into this directory (especially when you
consider things like uC-libc, diet-libc, and the like)...if a package is
dynamically linked against a c library, it probably needs to be catagorized
by the library flavor.
+ /glibc-none
-or-
+ /nolibc
dynamic executables that are not linked to libc, or are linked to libc
statically (but still dynamically linked to other packages)
+ /glibc-static
-or-
+ /static
packages that are statically linked, requiring no other libraries to
function
The entire point of my first post was to encourage using other subdirectorys
for packages that do not fit into the glibc-2.0 or glibc-2.1 catagories
rather than cluttering up the root packages directory...remember, it's hard
to move files once they're in CVS, so starting with a good directory
structure is a good thing...
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
