|
Home > Archive > Debian Developers > December 2007 > [proposal] Documenting which revision is installed
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[proposal] Documenting which revision is installed
|
|
| Martin Zobel-Helas 2007-12-26, 7:22 pm |
| Hi,
i would like to propose that we change /etc/debian_version with
beginning of lenny to also show which revision of a release is
installed.
Rational: We do regular updates to stable releases (called point
releases) from time to time but you can't tell from installed files
which revision (point release) is installed on a machine without knowing
the exact versions of packages in a debian revision.
The only way to determine which revision might be in use is to parse
/var/lib/apt/lists/$mirror_$path_dists_$release_Release which sucks.
My idea would be to have /etc/debian_version updated with every point
release to reflect the current revision.
There are different opinions out there (i spoke to several DDs already)
on how to reflect this in /etc/debian_version, thus i would like to get
consensus on this list first, before we start implementing it.
Here comes some ideas:
Lets say we have major version 4.0 (etch) and point release 2:
Idea 1:
4.0.2
Idea 2:
4.0r2
Idea 3:
4.0
r2
I personaly prefere Idea 1 over 3 over 2, but as said, i want to have an
consensus and i already heard several other ideas and/or complains.
Please flame^Wdiscuss now i threw the fish into the ring.
Greetings
Martin
--
[root@debian /root]# man real-life
No manual entry for real-life
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adeodato Simó 2007-12-26, 7:22 pm |
| * Martin Zobel-Helas [Wed, 26 Dec 2007 23:33:17 +0100]:
> Hi,
Hi.
I personally have nothing against. However, remembering the thread at
[1], I'm not sure what the base-files maintainer will think of that.
[1] http://lists.debian.org/debian-deve...5/msg01138.html
*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'"
I think this file would ideally live in the base-files package as well,
but: 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. And the base-files maintainer actually objects to maintaining
base-files in other flow that is not the normal flow for a package
(unstable->testing->stable).
For all this, I'm suggesting the creation of a new package (say,
release-info) containing that sole file, hopefully Priority: required.
If nobody objects, I would like to maintain it. (I'll file an ITP if
there's no strong opposition here; there wasn't any when I proposed the
same back in June in the above thread.)
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
One of my most productive days was throwing away 1000 lines of code.
-- Ken Thompson
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Luk Claes 2007-12-26, 7:22 pm |
| Martin Zobel-Helas wrote:
> Hi,
Hi
> i would like to propose that we change /etc/debian_version with
> beginning of lenny to also show which revision of a release is
> installed.
Ack.
> Rational: We do regular updates to stable releases (called point
> releases) from time to time but you can't tell from installed files
> which revision (point release) is installed on a machine without knowing
> the exact versions of packages in a debian revision.
> The only way to determine which revision might be in use is to parse
> /var/lib/apt/lists/$mirror_$path_dists_$release_Release which sucks.
>
> My idea would be to have /etc/debian_version updated with every point
> release to reflect the current revision.
Ack.
> There are different opinions out there (i spoke to several DDs already)
> on how to reflect this in /etc/debian_version, thus i would like to get
> consensus on this list first, before we start implementing it.
>
> Here comes some ideas:
> Lets say we have major version 4.0 (etch) and point release 2:
>
> Idea 1:
> 4.0.2
>
> Idea 2:
> 4.0r2
>
> Idea 3:
> 4.0
> r2
>
> I personaly prefere Idea 1 over 3 over 2, but as said, i want to have an
> consensus and i already heard several other ideas and/or complains.
I would prefer 2 over 1 and 3, though I think it's more important to
have it included in the file than any particular format :-)
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Anthony Towns 2007-12-27, 7:36 am |
| | |
| Adeodato Simó 2007-12-27, 1:25 pm |
| * Anthony Towns [Thu, 27 Dec 2007 17:34:49 +1000]:
> On Wed, Dec 26, 2007 at 11:53:25PM +0100, Adeodato Sim?? wrote:
[vbcol=seagreen]
> 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. :-)
However, I believe that most people wanting more detail in that file, or
another file, are aware of such limitations, but probably only are
seeking its use in scenarios where they'll now they'll not apply, eg. a
farm of machines which are just dist-upgrades, so it'll be up to date,
or not.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
He who has not a good memory should never take upon himself the trade of lying.
-- Michel de Montaigne
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Anthony Towns 2007-12-27, 7:26 pm |
| On Thu, Dec 27, 2007 at 04:21:20PM +0100, Adeodato Sim?? wrote:
> * Anthony Towns [Thu, 27 Dec 2007 17:34:49 +1000]:
> 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?)
> 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.
Cheers,
aj
| |
| Adeodato Simó 2007-12-27, 7:26 pm |
| * Anthony Towns [Fri, 28 Dec 2007 06:32:18 +1000]:
> On Thu, Dec 27, 2007 at 04:21:20PM +0100, Adeodato Sim?? wrote:
[vbcol=seagreen]
> 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.
[vbcol=seagreen]
> 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
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Frans Pop 2007-12-28, 7:33 am |
| Adeodato Simó wrote:
> 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).
The problem with that approach is that it is complex, error-prone and
requires a disproportionate amount of manual work, a lot of which can only
be done by someone with the access needed to set the needed hints.
> As said in my previous mail, I'm willing to take care of that.
For the next 40 years? Can you really guarantee that you will be able to do
this in time and without errors for each and every release and point release?
I agree with Anthony that it is very much preferable to have a solution
that's just able to automatically determine the correct version.
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Adeodato Simó 2007-12-28, 7:33 am |
| * Frans Pop [Fri, 28 Dec 2007 08:20:01 +0100]:
[vbcol=seagreen]
> For the next 40 years? Can you really guarantee that you will be able to do
> this in time and without errors for each and every release and point release?
Thanks for the vouch of confidence! Anyway, the package would be
maintained by the release team, and there should always be somebody
available to make a oh-so-trivial upload. Or somebody completely
different -- we know how to cover up for other people, ejem.
> I agree with Anthony that it is very much preferable to have a solution
> that's just able to automatically determine the correct version.
Feel free to pursue the idea, then, really, I'm just not interested in
*doing* it myself, whereas I'm interested in doing the package upload
dance. And this is Debian, after all.
And I'm leaving /etc/debian_version untouched, so it could be migrated
to Anthony's scheme if that turns out to besuccessful. But,
/etc/lsb-release ought to be a static file, I think.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Hay quien sueña con la alquimia
que haga del vicio virtud
-- Luis Eduardo Aute, Giraluna
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Petter Reinholdtsen 2007-12-28, 7:33 am |
|
[Anthony Towns]
> 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.
Why not move the /etc/debian_version file into a separate package, and
for example include the release documentation in that package. The
package could be called debian-version, and it would make it easier to
keep a separate version in testing and unstable.
The version number and the release notes are in my experience the last
two parts one want to update before a release, and it might make sense
to update those directly into testing, instead of going through sid.
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Anthony Towns 2007-12-31, 1:44 am |
| |
|
|
|
|