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
| s-p-u.
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.
Cheers,
--
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
Reply to: