(I keep looking at what I've written, and thinking "That's not quite right" or "I'm forgetting some critical argument" or "That sounds very argumentative/rude but I can't think of a better way to phrase it". I *have* gotten an interesting discussion out of this thread, however.)
Santiago Vila wrote: > That's the fundamental mistake I see here: We should not be telling > programs what "release" they are running to begin with. We do not try > to make packages to work under the assumption that they will run > "on a sarge system" or "an etch system". Instead, we try to make them work > as far as their dependencies are met. ... which means what, exactly, if my program expects /usr/lib/apache2/suexec but the system (stock Debian sarge) only has /usr/lib/apache2/suexec2? Or vice versa for etch? (Or more accurately, I need to know in advance - in this case, at package build time - which name suexec gets so that the Apache config fragment I drop in doesn't break.) OK, so if it's one file I can munge in a solution that checks at install time or something. What about a case where there are *hundreds* of little things like this with complicated subcases? This is the simplest, most prominent example I've run into, but it's far from the only one. Most of the rest are somewhat convoluted and specific to local systems (and a few are related to how I'm building packages to avoid Debian Policy limitations that conflict with local policy), but they're very real. I'm not trying to find something that includes (or resembles) significant fractions of the hairy mess that is an autotools configure script (<g>), but a reference I can use to make reasonable assumptions about what should be on the system if it hasn't been hacked fifteen different directions with source installs of half the major subsystems which rely on backports and packages from experimental. (Mildly amusing sidenote to this discussion: I'm finally convincing the senior systems guy that Packages Are Good, and now developers for the upstream OS seem to be telling me Packages Are Useless, because I can't even count on a critical dependency being installed via the package system. <g>) -kgd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
