[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: python-central 0.4



On Mon, Sep 30, 2002 at 08:13:23AM +1200, Carey Evans wrote:
> Donovan Baarda wrote:
> 
> >finding all packages that depend on "python" is non-trivial using only 
> >dpkg.
> >Something like dpkg-awk, grep-dctrl, or python-apt make it much easier, but
> >do we want to depend on them? The old "registry" idea would have made this 
> >a
> >little easier, but I still prefer using the dpkg database to find this kind
> >of info.
> 
> I prefer myself the way that packages like emacsen-common, mime-support, 
> menu and I'm sure others do this: by having every package using Python 
> and wanting to be recompiled install a script in (for example) 
> /usr/share/python-central/packages/<packagename>, which can be called 
> whenever .py files need recompiling.  Alternatively, it could just be a 
> configuration file with paths to the files to recompile.

python-central originally did have a "repository" where info about installed
packages was put that could then be used to recompile/whatever. However, it
was removed because there was nothing that this "repository" did that
couldn't be done by using the existing dpkg database, so it just included
redundant information that could have potentialy got out of sync.

I don't think that having a seperate compile script for each package
at /usr/share/python-central/packages/<packagename> is better than just
running "dpkg-reconfigure <package>". The only slightly tricky thing is
finding which packages need to be reconfigured, but all this info _is_ in
the dpkg database dependancies.

> Separate files that are part of the package would do the best job of 
> existing only when the corresponding .py files are also unpacked.

But this is redundant... if the package is installed, the corresponding *.py
files _should_ be unpacked. How is testing for the existance of a file any
better indication than testing for installation of the package?

> It also makes it easier for users to modify if a Python package's 
> dependencies are incorrect, and it stops compiling under a newer version 
> of Python, making the whole dpkg run fail.

This is an interesting issue I hadn't considered. However, I can't see how
seperate compilation scripts do a better job of avoiding this problem than
dpkg-reconfigure.

> >We only need to reconfigure/recompile when the default version of python
> >upgrades to a different version of python, not minor package upgrades. Is
> >there any way we can detect this and avoid un-necisary recompiles?
> 
> The python package itself knows from the arguments to its postinst, and 
> could pass this on to python-central.

So the postinst scripts get passed the version upgraded from? (I should know
this :-)

-- 
----------------------------------------------------------------------
ABO: finger abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------



Reply to: