On Sat, 23 Feb 2008 17:27:18 +0530 Kapil Hari Paranjape <[EMAIL PROTECTED]> wrote:
> Based on the above, I am inclined to close this bug report. Please > let me know one way or the other. If there was no update script or 'cron' job in 'swish++', I'd agree with upstream. But a system wide weekly update script is a Debian thing, and default package settings shouldn't overburden a system. If you don't have time to fix it, please just let it sit; that's what the 'wontfix' tag is for. I'm not (yet) sold on the current 'minor' severity. > ...Users should make judicious use of "ulimit" which is defined in > all Posix shells in order to set resource limits for child processes. The wiser maintainers can't generalize a 'ulimit' solution, yet expect ordinary users to figure out specific ones. How? No general solution means no standard for "judicious users" to apply. Result: clumsy trial & error, plus duplicated user effort. (BTW, I never installed 'swish++' on its own, it was a dependency of 'dhelp' or 'dwww'; both help viewers are perhaps most needed by novices who are the least able to cope with config problems.) Is this a new problem? As package 'cron' demands increase, I'd expect it to become a bigger problem. Clearly it's not up to 'swish++' to fix all of Debian, but it should play nice, and it's as good a place to start as any, a working particular solution may eventually lead to a general solution. It's about finding practical formulas for two variables: the proposed job load, and the system speed. It's virtually truck driving**, complete with freight limits, speed limits, time limits, mechanical failure, spoilage, traffic, and driver fatigue. (**any means of hauling would serve as a metaphor; freight trains, cargo ships, horse drawn wagons, donkey carts, dog sleds, bicycle baskets, rickshaws, etc.) Relevant unknowns, the "freight": how much resources needed to do a weekly 'cron' indexing. The worst case. Which single package, and which file, is "heaviest". The worst case would be if the user had the maximum number of indexable Debian packages installed. A few experiments with 'apt-get' suggest that finding this maximum is an interesting problem -- installing everything makes for conflicts, so thousands of packages must be whittled away. How to choose which packages? Fuzzy algorithm: come up with an average somehow, (e.g. my system, 2879 packages, I'm not sure how many can be indexed), multiply by 10. Kludge maximum package algorithm: scan all possible Debian packages, conflicting or not, for indexable files. (Either by searching the '.deb' archives without installing, for by 'forcing' installation on a dummy system.) Multiply average "weight" by 4. Relevant unknowns, the "truck": the user's system resources. if the maximum was feasible, even on a 386sx-16 with 32 megs, (or whatever the minimum Debian platform is), the problem becomes easier. If the minimal system can't make it, then we'd estimate how much it can do, and fail when necessary. Eventually, (should this be abstracted into a general solution), all Debian packages with cron jobs might be required to provide "freight" figures, (not necessarily actual numbers, perhaps just some partial formula invariant enough to work with), which would then be used at install-time, (or perhaps before downloading), to calculate whether the user's "truck" can haul some "freight". A "freight" figure would also be a useful metric for comparing the efficiency of similar packages. HTH... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
