* Javier Fernández-Sanguino Peña [Thu, 31 May 2007 12:33:07 +0200]: Hello.
> 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. Like Javier, I also think that it'd be desirable to have somewhere, be it /etc/debian_version or not, distinct information about the release. His idea about /etc/lsb-release sounds sensible to me: > 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)" Santiago, would you be willing to introduce this new file (distinct from /etc/debian_version) into base-files, and maintain two separate branches of the package as explained by Javier? If not, Javier's idea about introducing a new packagae for this file seems the only option left, and I wouldn't mind maintaining it. Other packages like lsb-release and maybe base-files could depend on it. Though I think it'd be best to ship /etc/lsb-release on base-files itself. > Either ways make the hacks introduced in lsb_release unnecesary. This sounds desirable, yes. Let's wait for Santiago's opinion. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org It is impossible to make anything foolproof because fools are so ingenious. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
