On Fri, 2006-01-13 at 12:04 +0100, Matthias Klose wrote: > Joe Wreschnig writes: > > On Thu, 2006-01-12 at 14:44 +0100, Matthias Klose wrote: > > > - modules are installed into a directory not directly in sys.path. > > > > While I understand the rationale here, this could be *very* confusing > > for people coming to Debian from other operating systems. > > People will find their modules in the standard place after > installation, handle by a script in the postinst. The only place > where you do see the difference will be the output from some tools > like `dpkg -L' and `dlocate'. Indeed; what I meant was that we should make sure this is very well-documented, not just for the packagers, but for any Python developers who might be surprised as well. One issue that comes to my mind now is behavior with regards to dpkg-divert. I've diverted a number of Python modules on my system; under this centralized registry I would have to divert them for all versions at once (which is fine for me now, but maybe not everyone), or better, make python-whateveritscalled understand diversions of the target (per-version) module names. > Private modules should be kept as they are. The existance of a > Python-Version attribute lets the central/support package know, that a > byte compilation with the new version is needed. Great, this is exactly what I was hoping for. > > Is this really feasible? The installed size will be, rough, source size > > * (the number of Python versions you have installed + 1), then * 2 if > > you have pyo files as well, since we're compiling for multiple versions. > > Since the installed size would vary based on the number of Python > > versions you have installed, an accurate report via APT would be > > impossible. > > dpkg does have support for the installed size, you could do that; > unless it's not done by some helper script nobody will use it anyway ;) Yes, but afaik Installed-Size is mostly used by APT to gauge disk space deltas when upgrading. Since it wouldn't know until the package was unpacked (and how many copies of the modules needed to be compiled were figured), this would prevent the most common case from working no matter what. It also wouldn't know that installing a new Python version would cause a lot of disk space usage as all the new modules were recompiled. So I think it's best not to guess at all, and at least be consistently inaccurate. > > This also blocks any Python program using dh_python from reaching > > testing until the issue is resolved, so it behooves us to do this > > quickly. > > that's understood. it's unfortunate that the package wasn't uploaded > to experimental first to sort out things. otoh, the change to > dh_python could be reverted in debhelper without doing any harm. I would also be very happy with reverting the dh_python changes, since right now, any built Python package is probably going to be completely useless regardless of what we end up doing. > > > Some things about python-support, others may comment about python-central: > > > > > > - Some concerns were raised by the release team, that python-support > > > tracks it's own state instead of using the dpkg database. To keep > > > track of usable python versions, python-central uses a field > > > Python-Version in the control file (having values like "2.3, 2.4", > > > "all", ">= 2.3") > > > > Is there some reason python-support couldn't be extended to also do > > this? I agree it is a better solution than a separate database. > > Joss didn't yet comment. I really do not want to have a packager/user to > understand two different things for extensions and modules, and > probably a third one for private modules. I guess I still don't totally understand -- from what I can see, python-support handles public and private modules already, and doesn't (can't, really) need to be invoked for extensions. I'm not sure any tool will significantly help C extensions, but that's okay, because I also don't see much wrong with how they're handled right now. The only potential change being storing all binary versions inside one .deb, which I can go either way on. Since the only extension module I'm going to maintain by the end of next week is huge and need separate versions anyway, I'd rather that be decided by the people it affects. -- Joe Wreschnig <piman@debian.org>
Attachment:
signature.asc
Description: This is a digitally signed message part