Re: policy 2.3 para 2
On Tue, Feb 12, 2002 at 10:17:16PM +, Julian Gilbey wrote:
> On Mon, Feb 11, 2002 at 10:19:56PM +1100, Donovan Baarda wrote:
> > > > Why not take the emacsen-common method and code and use this for
> > > > python? It probably won't work for C-extension modules, but it could
> > > > make life easier for pure Python ones.
> >
> > Just a thought; since we already have a database of packages in the form of
> > the dpkg database, is it possible to do something simple using it instead of
> > introducing some other database? As an example, can a python package call
> > "dpkg-reconfigure" for all installed packages that depend on "python" in
> > its postinst script?
>
> You have two cases to consider:
>
> (1) Installing/removing pythonX.Y package
>
> (2) Installing/removing a python-depending package
>
> Your suggestion will perhaps work for the former but not for the
> latter: every python package which wishes to use this scheme will have
> to have postinst code anyway.
[...]
This was just an off-the cuff suggestion intended to prompt some thinking...
Since doing some more thinking about it, I think I can see a way that it can
be done for both cases, but not easily or efficiently.
The trick is to have multi-version python modules have "Depends:
(pythonX.Y | pythonX.Y+1 | ...)" including every version of python they are
compatible with. This can be used to indicate what versions of python the
module should be sym-linked and compiled for when/if they are installed.
When a new python- is installed/removed, it's .post(inst/rm) script
calles a python-central style "register-python-package" to
symlink+compile/remove its .py's for all the currently installed versions of
pythonX.Y.
When a new pythonX.Y is installed/removed, it must find every package with a
pythonX.Y dependancy and symlink+compile/remove all files matching
/usr/lib/python/site-packages/*.py.
Perhaps something like;
# get_modules
# return all packages that have multi-version python modules that work for
# the specified
get_modules() {
VER=$1
RET=""
for p in dpkg -S /usr/lib/python/site-packages | sed 's#,##g; s#:.*$##'; do
if `dpkg -s $p | grep "^Depends:.*python$VER" >/dev/null 2>&1`; then
RET="$RET $p"
fi
done
}
> It may be that as python is simpler, we can simply have a script in a
> python-common package which does something like (pardon me if I get
[... sample scripts...]
It's funny how minds think alike... did you write these before or after
python-central, or did you base them on it. There is a lot in common :-)
--
--
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
--
Re: Bug#133306: apt-listchanges: Does not handle .pyc files correctly
On Fri, Feb 22, 2002 at 10:06:06PM +0100, Christian Kurz wrote: > On 22/02/02, Donovan Baarda wrote: > > First, remember that this tool is explicity for the subset of packages > > containing pure-python modules that work with multiple versions of Python. > > Well, but that's a good point for starting to change the setup and > handling of .pyo and .pyc files. If there's a new central solution using > python-register-package, I think we'll be able to find also a good > solution like this for packages which contain an executable python > script with addition .py files that contain used functions. So let's get > this sorted out and in place to get the rest also fixed. I consider anything that results in .pyo and .pyc files to be a "pure-python module", that includes additional .py files containing used functions. These are distinct from compiled python extensions. My initial impression is that a large number of "python-foo" packages are either compiled extensions, or tied specificly to particular versions of python. BTW, the python-register-package tool in python-central requires/assumes that any multi-version compatible .py files that need to be compiled into .pyc and .pyo files are installed into /usr/lib/python/site-packages. I think this is a valid assumption, but does everyone agree? I know there are some out there that think we should be using /usr/share/python and /usr/share/pythonX.Y. Can someone confirm/deny that .pyc and .pyo files are truely platform independant? Are there any endian-ness issues? -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: The Python Registrar
On Tue, Feb 12, 2002 at 12:05:22AM +0100, Bastian Kleineidam wrote: > Hello. > > The first version of the python-central package is online at > http://people.debian.org/~calvin/python-central/ > > It provides support for installing pure Python modules independent > of the Python version (see Python Policy 2.2.3). > > I made a patch for the python1.5 package which uses this script. > And there is a tiny example package. > > Use this script with care, its only tested with the example package. > To debug, add "set -x" at the top of /usr/bin/register-python-package. Did you see my analysis and modified "register-python-package" script? I posted it under a misleading subject by mistake (responded to another thread that migrated onto it). Any comments/corrections/abuse on my suggestions? :-) -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
