Re: when and why did python(-minimal) become essential?
On Sat, Jan 21, 2006 at 01:48:11AM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: One example is .config maintainer scripts, some of which are quite complex and worth writing in a higher-level language than shell. This is surely true; Steve Langasek asked if this was a real issue in Ubuntu or merely a potential issue. Granted if it is a real issue, then why not use perl? Yes, I hate perl too, but really, the argument hey, people like Python too implies that we should have a scheme interpreter, a perl, a python, emacs lisp, and well, everything anyone might want. Ubuntu developers would like to be able to use Python. So far there has been no demand whatsoever for LISP derivatives in this context. Or, we say we aren't going to support *every* high-level language and stick to one. We aren't going to support every high-level language, but we do support more than one in Ubuntu. This, of course, has no particular bearing on whether Debian follows suit. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Sat, Jan 21, 2006 at 01:04:25PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: Granted if it is a real issue, then why not use perl? Yes, I hate perl too, but really, the argument hey, people like Python too implies that we should have a scheme interpreter, a perl, a python, emacs lisp, and well, everything anyone might want. Ubuntu developers would like to be able to use Python. So far there has been no demand whatsoever for LISP derivatives in this context. Ok; Joe Wreschnig just said that I would like to write scripts in X is certainly not a good enough reason to add X to Essential. It sounds as if you are in disagreement with him; have I understood correctly.? I have said repeatedly that I am not expressing an opinion about what Debian does with regard to python-minimal. The only reason I am participating in this thread is to answer questions about what we did in Ubuntu and why, and I think I've done that thoroughly now. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 10:38:08PM -0800, Thomas Bushnell BSG wrote: Ok, but now I'm confused: why is python-minimal needed in Essential? Why not simply depend on it straightforwardly? Because there are parts of the packaging system where there is no way to express such a dependency relationship, and so only Essential packages can be relied upon to be available. One example is .config maintainer scripts, some of which are quite complex and worth writing in a higher-level language than shell. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Fri, Jan 20, 2006 at 09:40:55AM -0800, Steve Langasek wrote: I asked this question earlier, and no one answered. Are there .config scripts being written in python today in Ubuntu? (Hmm, where are the python bindings for debconf, and what ensures that they're installed?) No, not yet. The promotion to Essential needed to happen prior to writing any such scripts. The python bindings for debconf are, of all places, in the 'debconf' package. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Fri, Jan 20, 2006 at 02:05:40PM -0500, Joey Hess wrote: Matt Zimmerman wrote: On Thu, Jan 19, 2006 at 03:34:58PM -0500, Joey Hess wrote: If we followed the same method for python-base, then we would a) instroduce python-base iff we had some package(s) written in python that we wanted in the base system (apt-listchanges comes to mind) b) include only the modules needed by the package(s). Please don't do this; it implies that python-minimal would be part of base, but not full python, and this is something that python upstream explicitly objects to. It implies no such thing. If you won't acknowledge that, then know that upstream also object to the name python-base for something which has a stripped-down standard library. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 03:34:58PM -0500, Joey Hess wrote: If we followed the same method for python-base, then we would a) instroduce python-base iff we had some package(s) written in python that we wanted in the base system (apt-listchanges comes to mind) b) include only the modules needed by the package(s). Please don't do this; it implies that python-minimal would be part of base, but not full python, and this is something that python upstream explicitly objects to. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 09:23:30PM +, Martin Michlmayr wrote: * Matt Zimmerman [EMAIL PROTECTED] [2006-01-19 12:45]: Please don't do this; it implies that python-minimal would be part of base, but not full python, and this is something that python upstream explicitly objects to. Why? Surely having a sub-set of python is better than nothing at all, no? One of the appealing things about the Python language is their batteries included philosophy: users can assume that the standard library is available, documentation and examples are written to the full API, etc. When it's broken into pieces, they get complaints and support requests from their user community when things don't work the way they should. It is already a source of frustration to them that we don't install python-dev with python. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 05:58:20PM -0500, David Nusinow wrote: That said, I don't really understand why it's Ok for Ubuntu to do this but not us. Ubuntu never installs python-minimal without python, even in base. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 06:38:55PM -0500, David Nusinow wrote: On Thu, Jan 19, 2006 at 03:18:48PM -0800, Matt Zimmerman wrote: On Thu, Jan 19, 2006 at 05:58:20PM -0500, David Nusinow wrote: That said, I don't really understand why it's Ok for Ubuntu to do this but not us. Ubuntu never installs python-minimal without python, even in base. Ah, ok. Then why bother with the package at all then? Why not just make all of python Essential: yes? Because it has additional dependencies on packages which are not Essential: yes, and because -minimal is much smaller (if someone explicitly uninstalls it, along with the standard packages which depend on it), we can assume they are accepting the consequences). -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Fri, Jan 20, 2006 at 12:16:55AM -0500, David Nusinow wrote: Just to clarify, because I'm also confused and genuinely curious... you guys use the minimal package during bootstrapping or something and then by the end of the installation process you will necessarily have the full python somehow. Is this correct? python is part of the base system in Ubuntu. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 12:12:07PM +1000, Anthony Towns wrote: * allowing us to easily use python (as well as C, C++ and perl) for programs in the base system * allowing us to provide python early on installs to make users happier Please note that it is against upstream's explicit wishes for -minimal to be installed for users as part of a package selection which does not also include the full python package. In Ubuntu, we've split the package in order to make -minimal essential, but never install it alone (both are part of base). I don't know what's actually in (or more importantly not in) python2.4-minimal though. We basically reviewed the available modules and picked out the ones that we thought would be useful in an Essential context, with a goal of having no external non-Essential dependencies. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#315152: FTBFS: Missing build-dep(s)
On Tue, Jun 21, 2005 at 01:31:25PM +0200, Norbert Tretkowski wrote: severity 315152 wishlist thanks * Matt Zimmerman wrote: Package: bzr Version: 0.0.5-1 Severity: important Justification: fails to build from source python2.3 setup.py clean --all make: python2.3: Command not found Full log available at: http://people.ubuntu.com/~lamont/buildLogs/b/bzr/0.0.5-1/bzr_0.0.5-1_20050616-2010-i386-failed.gz This problem doesn't exist on Debian, because we still have python 2.3 as default, and a build-dep on python exists in the current bzr source package. It's still a bug, not a feature request. My understandis is that if you're invoking python2.3 explicitly, you need to depend on python2.3, not just python. Severity 'normal' or 'important' (depending on when Debian is moving to Python 2.4) would be appropriate. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fun with python-apt
On Sun, Jun 15, 2003 at 03:23:37PM -0400, Anthony DeRobertis wrote: In a perfect world, somehow the correct gcc would be used (to make sure C++ ABI problems don't happen). Not sure if we can have that perfect world or not; see below. No, we can't. Not today, and definitely not a year ago. According to 2.4.2, the package should build correctly. It did. However, it didn't run because you had an incompatible version of apt installed. If build-time dependencies are specified, it must be possible to build the package AND PRODUCE WORKING BINARIES In particular, this means that version clauses should be used rigorously in build-time relationships so that one CANNOT PRODUCE BAD OR INCONSISTENTLY CONFIGURE PAKAGES when the relationships are properly satisfied. (Policy 2.4.2, Emphasis added) 2.4.2 says the package has to work, too. Er, no. Those binaries would work perfectly fine if you had built apt with the same C++ ABI. But I can't specify in a build-dependency oh, and your apt must be built with the same C++ ABI. I _certainly_ can't do so retroactively. I am bothered by the implication that I did something wrong in building the python-apt package for woody. -- - mdz
Re: Fun with python-apt
On Sat, Jun 14, 2003 at 01:11:56AM -0400, Anthony DeRobertis wrote: I've managed to get python-apt (and thus apt-listchanges) working again on my testing system. What a PITA... Anyway, I first just tried to recompile python-apt-0.5.4.3. Compile went fine, but the first attempt to execute apt-listchanges failed with a dynamic linking error. C++ API change. First, I thought there was supposed to be a transition plan that would guard against such things happening. Is some package (apt?) not following it? If you had wanted to find out the answer before sending this to debian-devel, you would not have had to look very far. bugs.debian.org/python-apt has the answer three times over. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193566 -- - mdz
Re: Fun with python-apt
On Sat, Jun 14, 2003 at 12:28:30PM +0200, Bastian Kleineidam wrote: On Sat, Jun 14, 2003 at 01:40:12AM -0400, Matt Zimmerman wrote: If you had wanted to find out the answer before sending this to debian-devel, you would not have had to look very far. bugs.debian.org/python-apt has the answer three times over. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193566 That does not answer the questions. It does; it explains why the new python-apt has not entered testing. Specifically, because it depends on the new version of apt. The new version of apt, which is the only one to have been built with gcc 3.2+, still has RC bugs. -- - mdz
Re: Fun with python-apt
On Sun, Jun 15, 2003 at 01:05:37AM +0200, Bernd Eckenfels wrote: On Sat, Jun 14, 2003 at 06:45:21PM -0400, Matt Zimmerman wrote: According to 2.4.2, the package should build correctly. It did. However, it didn't run because you had an incompatible version of apt installed. The dependency system does not have a facility to handle this situation. Well, one can add the runtime dependency to the build dependency, or? Even if there were a reasonable way to do this (and I don't believe there is, but you can show me an example of what you mean), python-apt 0.5.4.3 was built March 10th, 2002. This was before woody released, before there was any kind of C++ ABI transition plan, before there was even a g++-3.2 in the archive. Surely you aren't suggesting that last year's build-dependencies should have anticipated this year's compiler ABI change. -- - mdz
Re: MailMan Security patch for Woody Broken?
On Thu, Aug 15, 2002 at 09:22:51PM +0200, Florent Rougon wrote: Matt Zimmerman [EMAIL PROTECTED] wrote: Python 1.5.2 (#0, Jan 13 2002, 13:19:04) [GCC 2.95.4 20011223 (Debian prerelease)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam ''.lower() Traceback (innermost last): File stdin, line 1, in ? AttributeError: 'string' object has no attribute 'lower' Good shot, but the latest mailman in woody (2.0.11-1woody2) depends on python and python depends on python2.1 (= 2.1.3-1), so I think there is something weird here. I'm bringing this discussion on debian-python. Please drop debian-devel on followups. I'll assume, then, that the security.d.o packages are fine unless someone from -python tells me otherwise. Please notify me promptly if they need to be fixed. -- - mdz
Re: Bug#133306: apt-listchanges: Does not handle .pyc files correctly
On Mon, Feb 18, 2002 at 12:33:55PM +0100, Christian Kurz wrote: On 17/02/02, Matt Zimmerman wrote: and this one package with one set of install/remove scripts supports emacs20, emacs21, xemacs21. When a new emacs is installed, the installed elisp packages are byte-compiled for it, and when one is removed, the byte-compiled files are removed. These packages don't have to build-depend on any emacs, much less multiple versions (as with these python packages). Well, but why can't you then use one generic install and remove script and pass it not only the version number but also the package name and let it then handle the byte-compiling? It would remove the need to add mostly identical scripts to the packages and therefor make it easier to maintain the packages. Good plan; why not do that for python? How about a /usr/sbin/python-pkgtool --install package /usr/sbin/python-pkgtool --remove package Which will have knowledge of which python versions are installed, and byte-compile/purge the appropriate files. That way, the logic about which versions are installed, and the details of byte compilation, stay out of module package maintainer scripts. One detail that needs to be handled is to only make the package available for the python versions that it works with. I don't like having multiple packages; for pure python modules the code often seems to work with multiple versions of python. -- - mdz
Re: Bug#133306: apt-listchanges: Does not handle .pyc files correctly
On Mon, Feb 18, 2002 at 07:02:02PM +0100, Bastian Kleineidam wrote: On Mon, Feb 18, 2002 at 12:48:02PM -0500, Matt Zimmerman wrote: Good plan; why not do that for python? How about a /usr/sbin/python-pkgtool --install package /usr/sbin/python-pkgtool --remove package Look at http://people.debian.org/~calvin/python-central/ Should we have a vote for the binary name? Currently the name is /usr/sbin/register-python-package Oh, good, I wasn't aware of this work. The name is not at all important to me; register-python-package is fine. I used pkgtool because I couldn't think of anything at the moment. -- - mdz
Re: Bug#133306: apt-listchanges: Does not handle .pyc files correctly
On Mon, Feb 18, 2002 at 01:35:25PM -0500, Jim Penny wrote: Objection 1: Autocompilation can result in progams that compile but do not work as expected. Examples: scope rule changes. Inheritance Changes. Arithmetic Changes. This has nothing to do with the organization of the packages; either way, the resulting programs must be tested (or if they aren't, things sometimes break). Objection 2: Autocompilation can produce programs which fail to compile. Examples. op=, use of mimelib (not available in 2.2), type/class unification, use of iterators/generators, etc. Some of these would be easy to backport to 1.5.2 (although probably not worth the effort), Certainly all would require a human decision. This doesn't sound like a problem at all. If a module doesn't compile, but runs when not compiled, then a compilation failure is simply not a fatal error. Objection 3: None of this addresses the case of 'C'-extension modules. Looking at my site-python2.1, I am guessing that this affects from 25% to 50% of all modules. These have to be hand-created with multiple packaging anyway. I wasn't exactly proposing a complete replacement for the python policy; my message was a short comment about one aspect of python module packaging. It did not address all cases. Objection 4: This is a minor objection: It would not be unusual to have at least two versions of python installed. (I currently have 3). I keep only current as a full featured package. I DO NOT want to have every package auto-installed and auto-compiled in every python on my system! This would be a simple matter of configuration. One of the benefits of a centralized scheme is that you can configure preferences like these in one place, rather than offloading a lot more work onto module packagers. Concluding remarks: It is simply not all that hard to create multiple python packages. This proposal simply offloads a minor amount of work from the packager, and a certain amount of storage from servers replacing it with greater package installation time and greater local storage use. What it does is to offload fundamentally fragile code from maintainer scripts into a centralized and easily maintained program. In addition, it has the added benefit of making module packaging easier, and not cluttering the archive with 3 (or 4, or 5) packages per python module. Worse, it hides problems from the packager. If the package compiles and works under the current python, I suspect that most developers will do no actual testing under old or leading edge pythons. And if they have not, the user contract is being violated. The packager may easily manage to inadvertantly install a broken package! This is no different from packaging for multiple versions, as above. Finally, the emacs compilation process is one reason that I make very sure that no emacs packages are installed on any of the systems I have control over. I find the compilation process to be at best annoying, and at worst a near denial of service. I would not welcome it in python. An exaggeration at best. -- - mdz
