Re: python transition and python-xml
On Sun, Aug 10, 2003 at 01:26:46PM +0200, Sebastien Bacher wrote: Hi, I need the python-xml package to rebuild some of my packages (python-gtk, python-gtk2, python-gnome2, python-pyorbit, rubrica), but python-xml is away from unstable because of transition. Several packages use python-gtk/gtk2, so I would upload these packages today, but I don't know what's the best way. * NMU python-xml (I've mailed the maintainer yesterday but no response for the moment). Yesterday was saturday, and I don't read my mail on week ends. The updated package is in progress (i.e. pbuilder is running right now), and I have contacted Jerome Marant who's my usual sponstor (I'm not a DD). I was planning to ask someone on the list to sponsor the upload if I don't get an answer from him by tomorow, but if people think this is more urgent, please tell me if you want to sponsor the upload today, and I'll give you the URL where you can dowload the source package for python-xml and python-unit. * change Build-Depends from python-xml to python2.3-xml for the moment. This will surely work in the meantime. -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Développement logiciel avancé - Intelligence Artificielle - Formations
Re: python 2.2 to python 2.3 transition
Le lun 11/08/2003 à 01:04, Donovan Baarda a écrit : you end up with multiple packages where the only difference is the versioned depends on python not very efficient. I'm not saying it is efficient, but it is simple and it works. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: python transition and python-xml
Yesterday was saturday, and I don't read my mail on week ends. The updated package is in progress (i.e. pbuilder is running right now), and I have contacted Jerome Marant who's my usual sponstor (I'm not a DD). I was planning to ask someone on the list to sponsor the upload if I don't get an answer from him by tomorow, but if people think this is more urgent, please tell me if you want to sponsor the upload today, and I'll give you the URL where you can dowload the source package for python-xml and python-unit. Ok, no problem. If Jerome is away I can make the upload. Cheers, Sebastien Bacher
Re: python transition and python-xml
Quoting Sebastien Bacher [EMAIL PROTECTED]: Yesterday was saturday, and I don't read my mail on week ends. The updated package is in progress (i.e. pbuilder is running right now), and I have contacted Jerome Marant who's my usual sponstor (I'm not a DD). I was planning to ask someone on the list to sponsor the upload if I don't get an answer from him by tomorow, but if people think this is more urgent, please tell me if you want to sponsor the upload today, and I'll give you the URL where you can dowload the source package for python-xml and python-unit. Ok, no problem. If Jerome is away I can make the upload. I am available and reachable by mail even ;-) Still waiting. -- Jérôme Marant
Re: python 2.2 to python 2.3 transition
Hi, Josselin Mouette wrote:
Hrm, this could be achieved quite simply, /methinks. It needs little
changes in dh_python and some prerm/postinst stuff in the python package
(not the pythonX.Y package) to rebuild all .pyc's and .pyo's in this
directory upon upgrade.
Matthias, do you think it is feasible ?
Would work for me. /usr/lib/site-python is supposed to have clean python
scripts only, so running compileall.py on all subdirectories thereof
should pose no problem.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
knghtbrd Windoze CEMeNT: Now with CrackGuard(TM)! Never worry about
unsightly cracks in Windoze CEMeNT again! CrackGuard(TM) is
so powerful that the entire thing will crumble before it will
crack. Order your $200 upgrade version today!
#!/usr/bin/python2.3 vs #!/usr/bin/env python2.3
Hello, Many Python programs use constructs like #!/usr/bin/env python2.3 to load themselves. Many others use #!/usr/bin/python2.3. On most Debian systems, these are the same. The submitter in #189473 claims that #!/usr/bin/env python2.3 is wrong because he has his own python2.3 on the path prior to the system's, and it doesn't necessarily have requisite libraries for the programs being run. Any opinions? -- John
Re: #!/usr/bin/python2.3 vs #!/usr/bin/env python2.3
John Goerzen writes: Hello, Many Python programs use constructs like #!/usr/bin/env python2.3 to load themselves. Many others use #!/usr/bin/python2.3. On most Debian systems, these are the same. The submitter in #189473 claims that #!/usr/bin/env python2.3 is wrong because he has his own python2.3 on the path prior to the system's, and it doesn't necessarily have requisite libraries for the programs being run. Any opinions? I think you should use the /usr/bin prefix to enforce the dependencies that your package has. After the temp. install in debian/* I use: : # Replace all '#!' calls to python with $(PY_INTERPRETER) : # and make them executable for i in `find debian/foo -type f`; do \ sed '1s,#!.*python[^ ]*\(.*\),#! $(PY_INTERPRETER)\1,' \ $$i $$i.temp; \ if cmp --quiet $$i $$i.temp; then \ rm -f $$i.temp; \ else \ mv -f $$i.temp $$i; \ chmod 755 $$i; \ echo fixed interpreter: $$i; \ fi; \ done
Re: #!/usr/bin/python2.3 vs #!/usr/bin/env python2.3
On Tue, 2003-08-12 at 06:50, John Goerzen wrote: Hello, Many Python programs use constructs like #!/usr/bin/env python2.3 to load themselves. Many others use #!/usr/bin/python2.3. On most Debian systems, these are the same. The submitter in #189473 claims that #!/usr/bin/env python2.3 is wrong because he has his own python2.3 on the path prior to the system's, and it doesn't necessarily have requisite libraries for the programs being run. The submitter is basically right. There have been discussions about this on this list in the past. However, the python policy has the following; Programs that can run with any version of Python should be started with `#!/usr/bin/python'. They must also specify a dependency on `python'. You're free to use `#!/usr/bin/env python', if you'd like to give the user a chance to override the Debian Python package with a local version. and; Programs which require a specific version of Python must start with `#!/usr/bin/pythonX.Y'. They must also specify a dependency on `pythonX.Y'. Again, if you're using `#!/usr/bin/env pythonX.Y', please be aware that a user might override the Debian Python package with a local version. Despite the Python Policy allowing you to use #!/usr/bin/env, the general consensus is that it is a bad idea. Package maintainers who choose to use it must be prepared to justify their decision and deal with bug reports from users with broken local installations of python. -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/
Re: python 2.2 to python 2.3 transition
On Mon, 2003-08-11 at 22:03, Matthias Urlichs wrote:
Hi, Josselin Mouette wrote:
Hrm, this could be achieved quite simply, /methinks. It needs little
changes in dh_python and some prerm/postinst stuff in the python package
(not the pythonX.Y package) to rebuild all .pyc's and .pyo's in this
directory upon upgrade.
Matthias, do you think it is feasible ?
Would work for me. /usr/lib/site-python is supposed to have clean python
scripts only, so running compileall.py on all subdirectories thereof
should pose no problem.
The problem I have with it is it doesn't take into account programs with
python modules outside /usr/lib/site-python. Probably mailman is the
prime example.
Currently packages with python modules are responsible for compiling and
removing their own pyc's and pyo's. Having the python package take
over and re-compile them might be risky.
I personally favour having the python package identify all packages that
depend on python and getting them to do the recompilation by
re-configuring them. This will work for packages that install *.py's
anywhere. The python package should do the same on removal, so packages
that have things like Depends: python | python2.1 can recompile
themselves with python2.1 if python disappears.
The pythonX.Y packages should do the same to notify packages that
optionally depend/support them that the pythonX.Y packages have been
installed/removed.
I know this is more complicated, but if we don't do this, we end up with
yet another half-solution, where version independent packages are only
supported if they put their modules in /usr/lib/site-python, and only
for multiple versions of python, not pythonX.Y.
The following is a code fragment for identifying all the installed
packages to be notified on install/remove of any python or pythonX.Y
package
# get_dependants package
# echo to stdout installed packages that depend on the specified package
# in any way.
get_dependants () {
PYTHONXY=$1
QUERYFORMAT='${Status}:${Package}:${Depends}\n'
dpkg-query --show-format=$QUERYFORMAT -W | \
egrep ^install ok installed:[^:]*:.*$PYTHONXY([ ,]|$) | \
cut -f 2 -d':'
}
Using this the python package can notify all packages that depend on
it by calling dpkg-reconfigure on them;
for p in `get_dependants python`; do
dpkg-reconfigure --priority=critical $p
done
This assumes packages will compile their own *.py's using a suitable
python when they are dpkg-reconfigured. Note this means packages that
have things like Depends: python (2.3) | python2.2 can choose to
fall-back to compiling with python2.2 when python (2.3) is installed.
I'm not sure if dpkg-reconfigure only does stuff for packages that use
debconf. If it does, than an alternative would be to call
/var/lib/dpkg/info/$p.postinst configure directly.
--
Donovan Baarda [EMAIL PROTECTED]
http://minkirri.apana.org.au/~abo/
Re: python 2.2 to python 2.3 transition
Hi,
Donovan Baarda wrote:
Using this the python package can notify all packages that depend on
it by calling dpkg-reconfigure on them;
That would work for me too, of course.
egrep ^install ok installed:[^:]*:.*$PYTHONXY([ ,]|$) | \
That regexp looks like it should look like this instead:
egrep ^install ok installed:[^:]*:(|.*[ ,])$PYTHONXY([ ,]|$) | \
so that it doesn't find packages which depend on packages which just happend
to end with $PYTHONXY. (Or perhaps you should rewrite that shell function in
Python. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: Das Zitat wurde zufllig ausgewhlt. | http://smurf.noris.de
--
Hallo Volksmusikgenieer!
