[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?

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

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 .. ]

> Try using dependencies or run-time tests. Really.

Which runtime tests do you suggest? If there is a programatic way to
implement the test then lsb_release is the way to do it.

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.

Could there be a distinct package per distribution repository? One
(cumbersome?) way to do this is to have base-files maintainer (ehem, you)
upload new versions of the package to the proper distribituion. That way, the
contents of /etc/debian_version in the package in sid are never changed, and
the contents of the file in testing depend on its status:

a) during development /etc/debian_version reads 'CODENAME/testing'
b) during freeze /etc/debian_verion reads 'CODENAME/stable' 
  (this way, when testing is released, it will ship with that content,
  right after the release a new package has to be uploaded to 'testing' to
  go back to a)

The only issue with this is that you have to maintain always two branches
(sid and the next release) and whenever changes to other files in base-fles
are done you have to upload them to both releases.

However, this opens the possibility of introducing /etc/lsb-release in Debian
(not required by lsb, but nice to have for people who do not want to rely on
the lsb_release script) with properly structured content like:

DISTRIB_DESCRIPTION="Debian GNU/Linux 4.0 'etch'"


DISTRIB_DESCRIPTION="Debian GNU/Linux testing 'lenny' (UNRELEASED)"

Another (easier?, but "strange") way to have this is to have base-files
depend: on a package like 'release-info' which only contained
/etc/debian_version and have different packages for each distribution which
are *not* transitioned from unstable->testing. 

Similary to the solution above, its maintainer (the RMs?) would have to
upload a new package in *testing* just before a release (for example, during
the freeze) and upload a new package version to *testing* just after a
release. The contents of the package in sid would never change.  However,
having a package just to handle a file looks like an overkill to me.

Either ways make the hacks introduced in lsb_release unnecesary.



Attachment: signature.asc
Description: Digital signature

Reply to: