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 12:48:02PM -0500, Matt Zimmerman wrote: 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. Objection 1: Autocompilation can result in progams that compile but do not work as expected. Examples: scope rule changes. Inheritance Changes. Arithmetic Changes. To my mind, all of these are issues that require human intervention or understanding, and simply autocompiling scripts will not detect problems. In particular, nested scopes are now default in 2.2 and were not available at all in 1.5.2. This is bound to have some interesting consequences. Simile with the embed the ring of integers into the field of reals fiasco. 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. 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. 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! 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. 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! 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. Jim Penny -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
[no subject]
FROM: MRS. MARIAM ABACHA C/O SHEWU ABACHA LAGOS - NIGERIA. 19TH FEB,2002 Fax: 234-1-759-0900 E-mail: [EMAIL PROTECTED] ATTN:PRESIDENT/CEO, I am Mrs. Mariam Abacha, the widow of late Gen. Sani Abacha. Former Nigeria military head of state who died mysteriouly as a result of cardiac arrest. Since after my husband`s death. my family has been going through immense harassment including undue police restriction and molestation . The family account with the bank here and abroad have been frozen by the government for reasons that are rather vindicative. Our plight ever made worse by the confiscation/ seizure of our family landed properties and investment in Nigeria. One of the witch-hunting search light of the government beamed on our account a Swiss bank which had a sum of US$ 700 Million in it and another US$ 450Million. Threats of freezing and clamp on the account have been too much. It is for this reason that I have decided to move the sum of US$ 60 Million in defaced form packed carefully in sealed metal boxes for reason of security.I humbly appeal to you on behalf of the entire family members to save us from starvation, poverty and strangulation by assisting us move the money into your country where it shall be safe, since I cannot leave Nigeria now due to the movement restriction place on us. You can reach us through our fax number above. Our Lawyer shall arrange a face to face meeting outside Nigeria for effective and logical movement of the money. You can equally get in touch with my younger son, Shewu Abacha (Mr) on his cellular phone number: 234-1-470-9814 or his e-mail address: ([EMAIL PROTECTED]) We will disclose to you the country the security company is located in west africa as soon as you show interest. My son shall give you details of this confidentially as soon as you get in touch. For the anticipated co- pperation, we have set 20% of the money for you while 75% shall be held on trust until we decide on a joint venture business to do with the money as soon as we regain freedom, while 5% shall be mapped out for any incidental expenses that may arise. Treat with confident and do reply to save us from the stifling grip of the merciless government. Best regards, Hajia Marian Abacha (Mrs
