-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 L Walsh wrote: > Micah Cowan wrote: >> I'm not sure what you mean about the linux thing; there are many >> instances of runtime loadable modules on Linux. dlopen() and friends are >> the standard way of doing this on any Unix kernel flavor. > ---- > I _thought_ so, but when I asked a distro why they didn't > use this, they said it would require rewriting nearly all currently > existing applications. > > My specific complain was against a SuSE distro, that in > in order to load one.rpm, it depended on two.rpm, which depended on > three.rpm, and that on four.rpm, etc. The functionality in "two.rpm" > was to load a library to handle "active directories" which, in my > non-MS, small setup, I didn't need -- and I didn't want to load > the 5-7 supporting packages for AD, since I didn't use them. > BUT, because of static-run time loading, one.rpm would fail if two.rpm > wasn't loaded...and so on and so forth. AFAIK, the same problem > exists on nearly every distro -- because no one bothers to think > that they might not want to load every package on the CD, just > to support local host lookup using...say nscd. Grrrr.
Ah, well, that's a different situation. In order to decide at runtime whether to load a runtime library or not, dlopen() is the standard way to handle that. However, if the application wasn't designed to make the decision at runtime, but rather at build time, then it does require code rewriting. In this case, though, we're specifically talking about loadable modules. We might choose to allow some of them to be linked at build time, but we'd definitely have to at least support conditional linking at runtime. >> Keeping a single Wget and using runtime libraries (which we were terming >> "plugins") was actually the original concept (there's mention of this in >> the first post of this thread, actually); > --- > Sounds good to me! :-) > >> the issue is that there are >> core bits of functionality (such as the multi-stream support) that are >> too intrinsic to separate into loadable modules, and that, to be done >> properly (and with a minimum of maintenance commitment) would also >> depend on other libraries (that is, doing asynchronous I/O wouldn't >> technically require the use of other libraries, but it can be a lot of >> work to do efficiently and portably across OSses, and there are already >> Free libraries to do that for us). > ----- > And perhaps that is the problem. In order to re-use existing > parts of code, rather than adopted them to a "load-if-necessary" type > structure -- everyone prefers to just use them "as is", thus one lib > references another, and another...and so on. Like I think you pull > in "cat", and you get all of the gnu-language libs and tools, which > pulls in alternate character set support, which requires certain > font rendering packages -- and of course, if you are display > alternate characters, lets not forget the corresponding foreign > input methods, and the asian-char specific terminal emulators...etc. That's retarded. Native Language Support for a terminal program shouldn't pull in font-rendering packages: displaying the characters properly is the terminal's responsibility. I have some trouble believing that any packagers would actually have such dependencies, but if they do, it's retarded. A program like "cat" should depend only on the system library, and (if NLS is supported) gettext (which shouldn't depend on anything else). > Can I jump off a cliff yet?...ARG! I hack around such problems, > at times, by extracting the 1 run-time library I need, and not the > rest of the package, but then my rpm-verify checks turn up supposed > "errors" because I'm missing package dependencies. Sigh... Frustrating experiences with RedHat's package management is why I'm now a Debian/Ubuntu user. :) > If one wanted to add multi-stream support, couldn't the > "small wget" have a check to see if the multi-stream support lib > was present (or not), and if so, set max-streams equal to one that > might yield the basic behavior one might want for the small wget? Well, but the actual support for having any sort of multi-stream is a major rewrite of the entire I/O code. Much better to use a separate library for that, if we can get it. In that case, it stops being something we can simply check for and use if it's available, but something that the code would absolutely require. > Not pushing a particular solution -- I, like you, am just throwing > out ideas to consider...if they've already covered the points I've > raised, feel free to just ignore my ramblings and "carry on"...:-) Well, and fortunately we've got plenty of time to talk about these things: my focus right now is on getting 1.11 out the door, after which there are _plenty_ of things to keep me busy for 1.12 (still a "lite" release) for quite some time. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHK4Tc7M8hyUobTrERCNHLAJ4nCbdcOA5pV9/Vnn5HrWf0NUBhrwCfVOK2 JWf7iMxejTPyCxu0BQ3rFHM= =oRpW -----END PGP SIGNATURE-----
