Re: [proposal] Documenting which revision is installed
On Fri, Dec 28, 2007 at 08:20:01AM +0100, Frans Pop wrote:
I agree with Anthony that it is very much preferable to have a solution
that's just able to automatically determine the correct version.
Okay, so here's a updated version that generates both debian_version and
lsb-release as specced by dato, if it's given arguments of debian-version
or dato-release, and has appropriate perms.
In order for it to be useful, I guess it'd need to be in base, and hence
written in perl or C (unless we decided to add python to base).
] $ ./debian_version.py debian-version
] /etc/debian_version should contain:
] lenny
] $ ./debian_version.py dato-release
] /etc/lsb-release should contain:
] DISTRIB_ID=Debian
] DISTRIB_RELEASE=lenny
] DISTRIB_CODENAME=lenny
] DISTRIB_DESCRIPTION=Debian x.y Testing distribution - Not Released
] $ ./debian_version.py noisy
] Packages seem to be from Debian release lenny
] Debian x.y Testing distribution - Not Released
] ['mirror.internode.on.net_pub_debian_dists_lenny_Release',
'http.us.debian.org_debian_dists_lenny_Release']
] 89.4% HIT RATE (1293 of 1447)
] 95.3% of installed packages available
] 4.4% of matching packages could be upgraded
] 1.8% of matching packages are more recent
] $ sudo rm /etc/debian_version /etc/lsb-release
] $ sudo ./debian_version.py debian-version dato-release
] $ cat /etc/debian_version; echo ; cat /etc/lsb-release
] lenny
]
] DISTRIB_ID=Debian
] DISTRIB_RELEASE=lenny
] DISTRIB_CODENAME=lenny
] DISTRIB_DESCRIPTION=Debian x.y Testing distribution - Not Released
Cheers,
aj
#!/usr/bin/env python
# Copyright 2007 Anthony Towns
# GPL v2 or later.
import apt_pkg, sys, os
apt_pkg.init()
def try_write(file):
try:
f = open(file, w)
except IOError:
f = sys.stdout
f.write(%s should contain:\n % file)
return f
def uniq(l):
return dict( [(x,1) for x in l] ).keys()
def get_installed():
vs = {}
i = open(/var/lib/dpkg/status, r)
p,v,x = None,None,None
for l in i.xreadlines():
l = l.rstrip()
if l.startswith(Package: ): p = l[l.find( )+1:]
if l.startswith(Version: ): v = l[l.find( )+1:]
if l.startswith(Status: ):
x = l.split( )[1:]
if l == :
if x and x[0] != hold and x[1] == ok and x[2] == installed:
vs[p] = v
p,v,x = None,None,None
i.close()
return vs
vlal = /var/lib/apt/lists
arch = .join(os.popen(dpkg --print-architecture, r).readlines()).rstrip()
def releases():
urs = {}
for path in os.listdir(vlal):
if not path.endswith(_Release.gpg): continue
path = path[:-4]
release_info = []
o,l,s,v,c = [None] * 5
for l in open(os.path.join(vlal,path)).xreadlines():
l = l.rstrip()
if l[0] != :
release_info.append(
(l[:l.find(:)], l[l.find(:)+1:].lstrip()) )
else:
x = release_info[-1]
x = (x[0], x[1] + \n + l[1:])
release_info[-1] = x
release_info_l = release_info
release_info = dict(release_info)
vendor = filter(None, [
release_info.get(Label, None),
release_info.get(Origin, None),
unknown] ) [0]
version = filter(None, [
release_info.get(Version, None),
release_info.get(Codename, None),
release_info.get(Suite, None),
unknown] ) [0]
pkgs = [x for x in os.listdir(vlal)
if x.startswith(path[:-7])
and x.endswith(_binary-%s_Packages % arch) ]
k = (vendor,version)
if k not in urs: urs[k] = ([],[],[])
urs[k][0].append( path )
urs[k][1].append( release_info )
urs[k][2].extend( pkgs )
res = []
for k,v in urs.iteritems():
(vendor, version) = k
(paths, rels, pkgs) = v
res.append( (vendor, version, paths, rels, readlist(pkgs)) )
return res
def readlist(files):
vs = {}
for file in files:
i = open(os.path.join(vlal, file), r)
p,v = None,None
for l in i.xreadlines():
l = l.rstrip()
if l.startswith(Package: ): p = l[l.find( )+1:]
if l.startswith(Version: ): v = l[l.find( )+1:]
if l == :
vs[p] = v
p,v = None,None
i.close()
return vs.items()
def compare(installed, list):
same, new, old = 0,0,0
tryagain = dict(installed)
for (p, tv) in list:
if p in installed:
if tv == installed[p]:
same += 1
del tryagain[p]
else:
x = apt_pkg.VersionCompare(installed[p], tv)
if x 0:
old += 1
elif x 0:
new += 1
else:
same += 1
del tryagain[p]
return same,new,old,tryagain
installed = get_installed()
release_pkgs = releases()
noisy = (noisy in sys.argv[1:])
iterate = (iterate in sys.argv[1:])
debian_version = (debian-version in sys.argv[1:])
dato_release = (dato-release in sys.argv[1:])
intro = Packages
while installed:
best = 0,len(installed),0,-,-,[],-,[]
for vendor, version, path, rels, packages in release_pkgs:
same,new,old,tryagain = compare(installed, packages)
if same best[0]:
best = same,new,old,vendor,version,rels,path,tryagain
Re: [proposal] Documenting which revision is installed
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [proposal] Documenting which revision is installed
* Frans Pop [Fri, 28 Dec 2007 08:20:01 +0100]: 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? 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [proposal] Documenting which revision is installed
[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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [proposal] Documenting which revision is installed
* 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. :-) 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [proposal] Documenting which revision is installed
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?) 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 signature.asc Description: Digital signature
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [proposal] Documenting which revision is installed
* 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-devel/2007/05/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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [proposal] Documenting which revision is installed
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [proposal] Documenting which revision is installed
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.
Maybe it would be better to have aptitude or similar actually analyse
what's installed compared to the available Packages/Release files,
and generate a /etc/debian_version or /etc/lsb-release file based on
that. It wouldn't require any additional downloads -- it'd just be a matter
of:
- looking at /var/lib/apt/lists/*_Release to see what the latest
available revision is
- looking at /var/lib/dpkg/status and /var/lib/apt/lists/*_Packages
to see if the packages on this system are actually updated to
that revision
- based on the above updating /etc/debian_version to reflect the
version of Debian actually installed
And that way the only things needed for getting the right version would
be (the equivalent of):
# update Release file
apt-get update
apt-get dist-upgrade
aptitude debian-version-update
with no need to worry about multiple branches of base-files or whatever,
or worrying what apt pinning says the admin's intending to install
or similar.
I'm at a bit of a loss as to how you'd do it properly (using python-apt
or something, say), but a proof of concept is attached. Example output:
$ ./debian_version.py
Packages seem to be from Debian release lenny
91.7% HIT RATE (1325 of 1445)
95.5% of installed packages available
2.2% of matching packages could be upgraded
1.8% of matching packages are more recent
$ ./debian_version.py
Packages seem to be from Debian release 4.0r1
87.3% HIT RATE (517 of 592)
97.3% of installed packages available
0.0% of matching packages could be upgraded
10.2% of matching packages are more recent
$ ./debian_version.py iterate
Packages seem to be from Debian release 4.0r1
87.3% HIT RATE (517 of 592)
97.3% of installed packages available
0.0% of matching packages could be upgraded
10.2% of matching packages are more recent
Remaining packages seem to be from Debian release 4.0-updates
61.3% HIT RATE (46 of 75)
68.0% of installed packages available
9.8% of matching packages could be upgraded
0.0% of matching packages are more recent
Remaining packages seem to be from Debian-Security release etch
10.3% HIT RATE (3 of 29)
24.1% of installed packages available
14.3% of matching packages could be upgraded
42.9% of matching packages are more recent
Remaining packages:
bzr: 0.15-1
...
Cheers,
aj
#!/usr/bin/env python
# Copyright 2007 Anthony Towns
# GPL v2 or later.
import apt_pkg, sys, os
apt_pkg.init()
def get_installed():
vs = {}
i = open(/var/lib/dpkg/status, r)
p,v,x = None,None,None
for l in i.xreadlines():
l = l.rstrip()
if l.startswith(Package: ): p = l[l.find( )+1:]
if l.startswith(Version: ): v = l[l.find( )+1:]
if l.startswith(Status: ):
x = l.split( )[1:]
if l == :
if x and x[0] != hold and x[1] == ok and x[2] == installed:
vs[p] = v
p,v,x = None,None,None
i.close()
return vs
vlal = /var/lib/apt/lists
arch = .join(os.popen(dpkg --print-architecture, r).readlines()).rstrip()
def releases():
urs = {}
for path in os.listdir(vlal):
if not path.endswith(_Release.gpg): continue
path = path[:-4]
o,l,s,v,c = [None] * 5
for l in open(os.path.join(vlal,path)).xreadlines():
l = l.rstrip()
if l.startswith(Origin: ): o = l[l.find( )+1:]
if l.startswith(Label: ):L = l[l.find( )+1:]
if l.startswith(Suite: ):s = l[l.find( )+1:]
if l.startswith(Version: ): v = l[l.find( )+1:]
if l.startswith(Codename: ): c = l[l.find( )+1:]
vendor = filter(None, [L,o,unknown])[0]
version = filter(None, [v,c,s,unknown])[0]
pkgs = [x for x in os.listdir(vlal)
if x.startswith(path[:-7])
and x.endswith(_binary-%s_Packages % arch) ]
k = (vendor,version)
if k not in urs: urs[k] = ([],[])
urs[k][0].append( path )
urs[k][1].extend( pkgs )
res = []
for k,v in urs.iteritems():
(vendor, version) = k
(paths, pkgs) = v
res.append( (vendor, version, paths, readlist(pkgs)) )
return res
def readlist(files):
vs = {}
for file
