Debian package: Missing dependency on Debian/etch #745
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#745
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Starting tahoe after upgrading a Debian/etch system to use the Debian Tahoe package 1.4.1-r3916 fails with this error message:
Perhaps including python-pysqlite2 as a dependency in debian/control would fix this?
Sorry, I forgot to mention that installing python-pysqlite2 manually fixed the problem.
Hrm, on python2.5, it's not supposed to declare a dependency on pysqlite (since 2.5 comes with sqlite in the standard library).
Zooko?
#728 was for adding this change. I grepped the current source code and the pysqlite requirement is guarded by an
if sys.version_info < (2,5)
. Could you make sure that sys.version_info looks correct on your system, and that this conditional is doing the right thing?Assigning to [4-tea-2] to investigate.
Incidentally, when Zooko asked me about adding this dependency declaration, I agreed to it only with the condition that it not cause exactly this sort of problem (setuptools has taught me to not trust its dependency calculations: I am constantly seeing it rebuild things which are already installed). If this turns out to be some sort of deep problem, I'll recommend that we remove the declaration.
setuptools installs requirements that are already installed (#657 ("python ./setup.py test" rebuilds packages), #717 (unnecessary rebuild of dependencies when tahoe-deps/ is present)), but I don't think I've seen it install something which wasn't required. My guess is that [4-tea-2] installed a .deb which didn't declare a dependency on sqlite2 (possibly because the .deb is in error? Or because it was a .deb for python 2.6?), and then ran it with Python 2.5.
[4-tea-2]: which .deb of Tahoe-LAFS did you install?
Thanks!
Formatted original report with wiki quoting.
Oh, when I wrote comment:71806, I was thinking that Python >= 2.6 comes with sqlite, but it is actually Python >= 2.5. [4-tea-2], would you please run the following and post the results?
? For example, here are the results on my machine:
Then, please look at the
_auto_deps.py
file which is in theallmydata-tahoe
package. For example, on my machine it is:The
_auto_deps.py
ought to be the same as the current trunk version: source:_auto_deps.py.Finally, please look at the
requires.txt
file in the.egg-info
, like this:This shows that on my machine
pysqlite
appears in therequires.txt
, because the .egg-info was built using Python 2.4. If you built with Python 2.5 thenpysqlite
should not appear in your.egg-info
. You could try rm'rf the wholeallmydata_tahoe.egg-info
directory and rebuilding.Thanks!
Ooh, I get it. [4-tea-2] didn't build the
.egg-info
himself, it came with the .deb that we built. So, we have to decide whether we want our .deb to depend onpython-pysqlite
, or whether we want it to not completely support Python 2.4 (or we could even build different .deb's for each Python version). I'm okay with either of those two options. (Not so much with the Python-version-specific debs option.)I guess that the build machine where the Debian packages are being created is using Python 2.4, so
pysqlite
is being added to the.egg-info
'srequires.txt
.Assigning to Brian to tell me what our policy is about .debs and pysqlite.
Sigh. So, building separate .debs for py2.4/py2.5/py2.6 is painful (nobody does it anymore, now that debian-python-policy generates .pycs at install time). And I don't believe the .deb control-file "Depends:" format isn't rich enough to express (py>=2.5 or pysqlite).
On the other hand, the "standard" version of python is well-known per-platform (it's 2.4 in the older ones, 2.5 in the newer ones, and I guess Ubuntu Karmic will probably have 2.6). So we could say that when we build a .deb on a platform with /usr/bin/python=2.4, we declare the dependency upon pysqlite, and when we build it on a py2.5-using platform, we don't.
To implement this, we should update the misc/*/debian/control files to declare the pysqlite dependency on the older platforms, and leave the newer ones alone (not declaring it).
This also means that we should probably stop using the feisty rules for all platforms.. we at least need to identify the release for which python switched to 2.5 and use a newer set of rules for the 2.5-using set.
I'll try to look at this today, but I'm not sure I'll get the time.
Ok, I think I understand this better now.
(http://packages.debian.org/etch/python).
(http://allmydata.org/debian/dists/etch/tahoe/binary-i386/allmydata-tahoe_1.4.1-r3916_all.deb)
was built on an Etch system with python2.4
_auto_deps.py
correctly declares a requirement onpysqlite, enforced at runtime, via the call to
require_auto_deps()
in
src/allmydata/*init*.py
requires
pysqlite >= 2.0.5
, which will probably be enforced byanything that goes poking around .egg-info . In particular, the code that
was added to src/allmydata/scripts/runner.py (the main CLI entry point)
to call
pkg_requires.require('allmydata-tahoe')
will read the.egg-info data and enforce its requirements.
requirement. This is a bug. Installing just this .deb (and no extra
non-Depends-required packages) and then running the supplied
/usr/bin/tahoe with python2.4 should fail with the same sort of exception
displayed, because
_auto_deps.py
insists on having pysqlite, but APTdid not know that python-pysqlite2 should have been installed.
etch system, because the traceback listed above shows
/usr/lib/python2.5/site-packages
. Etch includes a python2.5 package(http://packages.debian.org/etch/python2.5), but it does not touch
/usr/bin/python, so either 4-tea-2 has set up a symlink or installed
python2.5 outside the awareness of APT (perhaps directly to
/usr/local/bin). This is what was confusing me.
directory, and does not provide any .egg-info data for python2.5 . I
don't know how setuptools reacts to this: would it refuse to believe that
tahoe was actually installed when run under py2.5? If so, then I'm still
confused as to where 4-tea-2's tahoe was finding the .egg-info data.
_auto_deps.py
should notrequire pysqlite
requires it, and thus the scripts/runner.py call will demand it.
Why is that
pkg_resources.require('allmydata-tahoe')
line there? If itweren't, then the correct runtime-computed dependencies in _auto_deps.py
would be enforced, and the incorrect package-build-time dependencies in
.egg-info/requires.txt would not.
Now, it happens that the .deb packaging for this is incorrect, and the Etch
.deb should declare a dependency on python-sqlite2 because that's needed by
the default version of python on an Etch system, and it happens that fixing
the packaging would also happen to make this problem go away. But it's still
wrong: this is a dependency that changes depending upon the version of Python
used to run bin/tahoe, and recording the value that was computed at
package-build time seems inappropriate. It should be possible to run tahoe
under py2.5 on this system without having pysqlite installed.
I guess a quicker solution is just to have the
allmydata-tahoe
.deb always depend onpython-sqlite
. While we're at it, I can swap the order of attempted-import in source:src/allmydata/init.py and source:src/allmydata/scripts/backupdb.py, so that whateverpython-sqlite
package that is installed is the one that actually gets used (in preference to thesqlite
module that comes in the Python standard library).My comment:71812 was in reply to your comment:71810, not your comment:71811.
I updated the debian packaging rules last night, and now the py2.4-based distributions (etch and edgy, I believe) add a python-sqlite2 dependency, and the more recent ones do not. I'd prefer to not force py2.5-based platforms to install an extra package. And I'd prefer that we use the stdlib
sqlite3
module in preference to an externalpysqlite2
module. Think about it this way: when py2.4 is long dead, do you still want us to be requiring people to install a third-party module to duplicate stdlib functionality?Thanks, Brian!