[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

(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>)


Reply to: