Help needed with #159208
Wajig, once upon a time, compiled its .py files. That wasn't really useful as the performance bottlenecks come from the externally called programs, not wajig itself. So I removed that a while ago. However, the versioned Depends and Build-Depends persisted ... and so I just got a bug report, #159208. In response, I am about to suggest the following: wajig (0.3.13-2) unstable; urgency=low * debian/control: Depends changed to python -- we do not need versioned Depends as .py[co] file are not (anymore) shipped (Closes: #159208) * debian/control: Similarly, Build-Depends simply on python-dev -- Dirk Eddelbuettel <[EMAIL PROTECTED]> Thu, 5 Sep 2002 06:41:10 -0500 Is that ok with you Python Meisters? Wajig will only ever ship interpreted Python files and does run with all recent Python versions. Lintian and Linda are fine with it, but these robots might not have perused the Python Policy lately. Please CC me as I'm not subscribed here. Dirk -- Good judgement comes from experience; experience comes from bad judgement. -- Fred Brooks
Re: Help needed with #159208
On Thu, Sep 05, 2002 at 06:48:40AM -0500, Dirk Eddelbuettel wrote: > > In response, I am about to suggest the following: > > wajig (0.3.13-2) unstable; urgency=low > > * debian/control: Depends changed to python -- we do not need versioned > Depends as .py[co] file are not (anymore) shipped (Closes: #159208) > * debian/control: Similarly, Build-Depends simply on python-dev > > -- Dirk Eddelbuettel <[EMAIL PROTECTED]> Thu, 5 Sep 2002 06:41:10 -0500 > > Is that ok with you Python Meisters? Wajig will only ever ship interpreted > Python files and does run with all recent Python versions. You should depend on exactly the Python versions you support, not on "python". For example Depends: python1.5 | python2.1 | python2.2 And if you dont compile any Python packages, why do you still have to build-depend on python-dev? Tschöö, -- Bastian Kleineidam reflexionsniveau AT web.de calvin AT users.sf.net calvin AT debian.org pgpirebmXK9Xk.pgp Description: PGP signature
python-unit package
Hello, I'm the current maintainer for python-unit, and I'm wondering on the need to have this package as a separate one. The main reason for the existence of this package is for python1.5 users, since pyunit is part of the main python distribution since 2.0. The problem I have is that upstream has not made any new release since 1.4.1 in august 2001, whereas the code for pyunit in the different python releases has evolved. As a consequence, python2.2-unit-1.4.1 is outdated with regards to what would be available from the python2.2 source package. The questions are: * should the python-unit package be generated from the python source package? * if so, do we drop support for pyunit in python1.5, or add pyunit as a patch? * if not, should I generate python-unit packages based on the CVS? * or should I ask upstream to make a release? Thanks for your feedback. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL).
Re: python-unit package
On Thu, Sep 05, 2002 at 02:45:39PM +0200, Alexandre wrote: > * if so, do we drop support for pyunit in python1.5, or add pyunit as a > patch? Forget this line: the pyunit package is not built for python1.5. Alexandre Fayolle -- LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Narval, the first software agent available as free software (GPL).
Re: Help needed with #159208
> You should depend on exactly the Python versions you support, not on > "python". For example > Depends: python1.5 | python2.1 | python2.2 I see. But why not simply "Depends: python (>= 1.5)" > And if you dont compile any Python packages, why do you still have to > build-depend on python-dev? Quite right, good point -- thanks. Tschoe mit oe, Dirk -- According to the latest figures, 43% of all signatures are totally worthless.
Re: Help needed with #159208
On Thu, Sep 05, 2002 at 07:48:38AM -0500, Dirk Eddelbuettel wrote: > > > > You should depend on exactly the Python versions you support, not on > > "python". For example > > Depends: python1.5 | python2.1 | python2.2 > > I see. But why not simply "Depends: python (>= 1.5)" I think this is wrong. If this is a package with python scripts, then they will probably have '#!/usr/bin/python', in which case the dependancy should be; Depends: python (>=1.5), python (<<2.3) You could make a package of scripts that could work with "python1.5 | python2.1 | python2.2", but it would either require seperate foo-python1.5, foo-python2.1, and foo-python2.2 scripts, or some sort of smart dispatcher that could find and run the right installed /usr/bin/pythonX.Y. Remember, /usr/bin/python is a symlink installed by the "python" package, and without a dependancy on this package there is no gaurentee that it will be there. You can't just use "#!/usr/bin/python" without depending on the "python" package. > > > And if you dont compile any Python packages, why do you still have to > > build-depend on python-dev? > > Quite right, good point -- thanks. I _think_ you are saying that this package used to include compiled "*.py[oc]" files and now it doesn't. That is good. However, if it still includes *.py modules that are "imported", then you still need to be very careful. Python will create and save "*.pyc" files when these modules are imported. However, typicaly only root has write access to the directories where these *.py files are installed. This means these *.pyc files are only created when root runs the scripts that import them. Worse, if the default python is upgraded, then the old *.pyc files cannot by "updated" by python, and hang around until root happens to "import" them again. I'm pretty sure python silently doesn't save *.pyc files if it can't, making them be re-compiled every "import". It also re-compiles them if the *.pyc's are from a different version of python. This means worst case, python silently checks existing *.pyc's, recompiles them, then throws them away for every run. The proper way of handling this is for the postinst scripts to compile the *.pyc modules, and the postinst script to remove them. The really complicated stuff starts to happen when these script+module packages support multiple versions of python... If you need more info on this just ask. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: Help needed with #159208
> On Thu, Sep 05, 2002 at 07:48:38AM -0500, Dirk Eddelbuettel wrote: > > > > > > > You should depend on exactly the Python versions you support, not on > > > "python". For example > > > Depends: python1.5 | python2.1 | python2.2 > > > > I see. But why not simply "Depends: python (>= 1.5)" > > I think this is wrong. If this is a package with python scripts, then they > will probably have '#!/usr/bin/python', in which case the dependancy should > be; > > Depends: python (>=1.5), python (<<2.3) > > You could make a package of scripts that could work with "python1.5 | > python2.1 | python2.2", but it would either require seperate foo-python1.5, > foo-python2.1, and foo-python2.2 scripts, or some sort of smart dispatcher > that could find and run the right installed /usr/bin/pythonX.Y. > > Remember, /usr/bin/python is a symlink installed by the "python" package, > and without a dependancy on this package there is no gaurentee that it will > be there. You can't just use "#!/usr/bin/python" without depending on the > "python" package. Aren't we now fully circular? At first I suggested "Depends: python", and now you recommend the same to me. I guess I need more coffee... And what about the #!/usr/bin/env trick? Can't that be used to call whatever suitable python interpreter is found in the $PATH? > > > > > And if you dont compile any Python packages, why do you still have to > > > build-depend on python-dev? > > > > Quite right, good point -- thanks. > > I _think_ you are saying that this package used to include compiled > "*.py[oc]" files and now it doesn't. That is good. Correct. > However, if it still includes *.py modules that are "imported", then you > still need to be very careful. Python will create and save "*.pyc" files > when these modules are imported. However, typicaly only root has write > access to the directories where these *.py files are installed. This means > these *.pyc files are only created when root runs the scripts that import > them. > > Worse, if the default python is upgraded, then the old *.pyc files cannot by > "updated" by python, and hang around until root happens to "import" them > again. > > I'm pretty sure python silently doesn't save *.pyc files if it can't, making > them be re-compiled every "import". It also re-compiles them if the *.pyc's > are from a different version of python. This means worst case, python > silently checks existing *.pyc's, recompiles them, then throws them away for > every run. It is somewhat of a non-issue "by design" as wajig is written to be a higher-level wrapper around tasks requiring root. But wajig is only ever called as a normal user, and if and when su powers are needed, sudo is invoked /from inside the python script/ so that no python code should ever run as root. > The proper way of handling this is for the postinst scripts to compile the > *.pyc modules, and the postinst script to remove them. The really complicated > stuff starts to happen when these script+module packages support multiple > versions of python... If you need more info on this just ask. I sort-of-know as I once went that route, but it turned out to create only headaches. A simple "Depends: python" still looks terribly appealing to me. Dirk (who quite likes the kiss principle) -- According to the latest figures, 43% of all signatures are totally worthless.
Re: Help needed with #159208
On Thu, Sep 05, 2002 at 07:48:38AM -0500, Dirk Eddelbuettel wrote: > I see. But why not simply "Depends: python (>= 1.5)" I made the experience[*] that I cannot guarantee support for future Python versions (in this case Python >> 2.2). There is always some little detail that breaks. So I give in my packages exactly the Python versions I can test and verify. [*] I got bitten by the list.append(a,b) --> list.append((a,b)) change, and the variable scope changes for local variables. Cheers, Bastian -- Bastian Kleineidam reflexionsniveau AT web.de calvin AT users.sf.net calvin AT debian.org pgpbBsmr0B6TS.pgp Description: PGP signature
python_2.2.1-10 contains a file in common with idle-python2.1
Hi when upgrading python in unstable I get the following. Preparing to replace python 2.1.3-6a (using .../python_2.2.1-10_all.deb) ... Unpacking replacement python ... dpkg: error processing /var/cache/apt/archives/python_2.2.1-10_all.deb (--unpack ): trying to overwrite `/usr/share/man/man1/pydoc.1.gz', which is also in package idle-python2.1 Errors were encountered while processing: /var/cache/apt/archives/python_2.2.1-10_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Regards Rob
