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 [EMAIL PROTECTED] for more info, including pgp key ----------------------------------------------------------------------
