> > 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.
Any interest in a uClibc branch (or uClibc content in a non-glibc branch)? > + /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 A primary classification based on dynamic linkage to a particular C-library is clean and useful, but I'm not sure what would be gained by bringing in dependence on other libraries or packages (at least at this level) For example, I can imagine a package consisting of shell scripts that extend weblet.lrp (hence in + /nolibc). Why should this package be in a separate branch from seawall.lrp, which requires no other packages or libraries to function (hence in + /static). > 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 -Richard _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
