Re: Is there a way to positively, uniquely identify which Debian release a program is running on?
On Thu, 31 May 2007, Javier Fernández-Sanguino Peña wrote:
> On Thu, May 31, 2007 at 12:35:06AM +0200, Santiago Vila wrote:
> > Hi.
> >
> > I believe there is something fundamentally wrong if you *have* to rely
> > on /etc/debian_version for anything. The number of Debian packages
> > actually using such file is probably zero (but I could be wrong).
>
> Bastille uses it to distinguish releases. There seems to be others:
>
> $ grep -l /etc/debian_version /*/bin/* 2>/dev/null
> /usr/bin/binstats
> /usr/bin/bug-buddy
> /usr/bin/euro-test
> /usr/bin/gnome-bug
> /usr/bin/gst-feedback-0.8
> /usr/bin/imake
> /usr/bin/lsb_release
> /usr/bin/xine-bugreport
> /usr/bin/xine-check
> /usr/bin/xminicom
Using them (to show its contents, for example) is one thing, relying
on them to achieve different behaviour is another one. The former
might be acceptable, the latter should not be.
> And this is NOT surprising for people who use linuxlogo:
>
> $ find /var/lib/dpkg/info/ -type f -exec grep -l /etc/debian_version \{\} \;
> [ .. snip base-files .. ]
> /var/lib/dpkg/info/linuxlogo.preinst
> /var/lib/dpkg/info/linuxlogo.postrm
>
> > Try using dependencies or run-time tests. Really.
>
> Which runtime tests do you suggest? [...]
Consider the example given by Kris: If you need to know how apache
does such and such, you should rely on the actual apache version you
have installed, not on base-files, because the user might have a mix
of packages from sarge and etch.
> I actually think we should ship a *distinct* /etc/debian_version
> in testing and not make it follow the "sid->testing->stable" dance. Otherwise
> there is a timeframe in which sid's or testing's base-files say's it is
> stable, when it's not.
That would "bless" the abuse of /etc/debian_version. IMHO, it would be
good for Debian if we continue to discourage its use.
A lot of time ago, there was a paragraph somewhere (policy? packaging manual?)
saying something like "Debian packages are not tied to a given release"
and the dependency system has allowed us so far to keep the spirit of that.
Reply to: