Re: [proposal] Documenting which revision is installed
* Anthony Towns [Fri, 28 Dec 2007 06:32:18 +1000]:
> On Thu, Dec 27, 2007 at 04:21:20PM +0100, Adeodato Sim?? wrote:
> > * Anthony Towns [Thu, 27 Dec 2007 17:34:49 +1000]:
> > > On Wed, Dec 26, 2007 at 11:53:25PM +0100, Adeodato Sim?? wrote:
> > > > *Personally*, I like the idea of Javier Fern??ndez-Sanguino expressed in
> > > > the mail linked above of keeping debian_version as is, and introducing
> > > > /etc/lsb-release with detailed information like:
> > > > DISTRIB_ID=Debian
> > > > DISTRIB_RELEASE=4.0
> > > > DISTRIB_CODENAME=etch
> > > > DISTRIB_DESCRIPTION="Debian GNU/Linux 4.0 'etch'"
> > > The problem with base-files providing /etc/debian_version is that it means
> > > /etc/debian_version can really only tell you what version of base-files
> > > is installed. So if you upgrade every other package but base-files from
> > > 4.0r1 to 4.0r2, you have all the functionality of 4.0r2 but get reported as
> > > 4.0r1, and if you just upgrade base-files, you get reported as 4.0r2 while
> > > still having the bugs from 4.0r1 that were meant to have been fixed.
> > Yes, of course. And this is brought up whenever there's talk about
> > /etc/debian_version. :-)
> Right, so why not fix it properly? (Did you read the rest of my mail?)
Yes, I did, and thanks for it. Sorry I didn't comment, but albeit I
think it's indeed an interesting new concept, at the moment I prefer to
focus in a more readily available solution, the normal package.
> > However, I believe that most people wanting more detail in that file, or
> > another file, are aware of such limitations,
> The main limitation is that it's a nuisance to update -- you can't
> differentiate testing and unstable because of that, eg, and when we're due
> for a release we end up having testing/unstable pretend they're really
> stable already for a while, eg. Updating it more often just makes that
> more of a nuisance.
Well, in my first mail I said:
| for this file to be meaningful, it would have to have three
| branches, one uploaded via sid, another via t-p-u, and another via
In other words, I plan on uploading a version to sid, block it from
migrating to testing, and uploading another version via t-p-u. Stable
point releases will get updated via s-p-u. That makes it two initial
uploads, and then twice per stable release (t-p-u; release; t-p-u), plus
one per stable point release (s-p-u). As said in my previous mail, I'm
willing to take care of that.
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
La música es de los que la quieren escuchar y de nadie más.
-- Andrés Calamaro