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
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? 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_ID=Debian
DISTRIB_RELEASE=4.0
DISTRIB_CODENAME=etch
DISTRIB_DESCRIPTION="Debian GNU/Linux 4.0 'etch'"
and
DISTRIB_ID=Debian
DISTRIB_RELEASE=testing
DISTRIB_CODENAME=lenny
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.
Regards
Javier
Attachment:
signature.asc
Description: Digital signature