On 4/16/02 at 3:46 PM, Charles Steinkuehler <[EMAIL PROTECTED]> wrote:
> I guess so, but I sort of got the idea (perhaps incorrect) > that there were packages that *did not* require a C > library. I'm sure there are... > 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. However, some programs have OTHER library requirements. So I think I'd be tempted just to have "noglibc" and a "lib" directory for the libraries: --+--- glibc2.0 | +--- glibc2.1 | +--- glibc2.2 | +--- noglibc | +--- libs Thus, elvis.lrp would be in glibc2.0 - even though it requires libm.lrp (in libs) and ncurses5.lrp (in libs). e3.lrp would be in noglibc, however. I would suggest that these directories be used for archives, and for source code. My personal Oxygen tree is shaping up like the FreeBSD /usr/ports directories - and I would suggest this. It has the benefits of: 1. No binary code to watch over... 2. Smaller repository: just makefiles and patches. 3. Much more automated, and can generate packages on the fly - so a glibc 2.0 program could be compiled for glibc 2.2 if one wanted. Now that I think of it, the above graphic tree would be bad for development CVS archives: 1. A program that used to compile under glibc 2.0 but didn't any longer would have to have its entire CVS tree moved. 2. One could never be sure where a package was. A perfect (recent) example: a program called "remark" (or regex-markup): the first version compiled under Red Hat 6.2; the latest version has gcc requirements that mean it won't compile on less than Red Hat 7 something (7.2 in my case). I think ntop had some requirements that way too - the networking code was nasty that way; a lot of networking details seem to change between glibc 2.0 systems and glibc 2.1 systems. -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] _______________________________________________ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
