Hello Julian, On Wed, Apr 27, 2011 at 01:07:49PM +0200, Julian Andres Klode wrote: > On Do, 2011-04-21 at 16:57 +0200, Pietro Abate wrote: > > On Thu, Apr 21, 2011 at 03:53:39PM +0200, Julian Andres Klode wrote: > > > On Mi, 2011-04-20 at 19:06 +0200, Pietro Abate wrote: > > > > This is a request to add a new binding to the class pkgOrderList of apt. > > > > The idea is to allow to compute and set the pkgOrderList independently > > > > and reason about it. > Attaching a diff for review. Also see > http://apt.alioth.debian.org/python-apt-doc/library/apt_pkg.html#apt_pkg.OrderList > > Note that this only adds a new OrderList class, it does not provide any > integration with PackageManager. If you wish to have integration, please > tell me how you'd like it to be.
This is great. I had a look at the code and doc and it seems good so far. I re-read the apt-pkg code regarding the packagemanager class and maybe I've a suggestion on a possible integration with the work you have done. the packagemanger has a number of virtual methods that are instantiated in apt-pkg/deb/dpkgpm.cc . These methods are protected in the packagemaneger class : // The Actual installation implementation virtual bool Install(PkgIterator /*Pkg*/,string /*File*/) {return false;}; virtual bool Configure(PkgIterator /*Pkg*/) {return false;}; virtual bool Remove(PkgIterator /*Pkg*/,bool /*Purge*/=false) {return false;}; virtual bool Go(int statusFd=-1) {return true;}; virtual void Reset() {}; the packagemaneger object is created in cmdline/apt-get.cc by a call to this function: SPtr<pkgPackageManager> PM= _system->CreatePM(Cache); In apt-get, if "Simulated" is specified, the package manager will be instantiated as a pkgSimulate object (that is a concrete implementation of packageManager ). The problem is that this class does not save the installation plan anywhere it only prints it on screen. My proposal of integration will be very simple. We can create a new subclass of packageManager , say pkgPlan that will implement install, configure, remove, etc and instead of printing on stdout the actions as in pkgSimulate, will save this information in a list that can be for our purposes. Since the dpkg commands are built in yet another packageManager object derived from apt-pkg/deb/dpkgpm.cc I don't think it will be easy to get a trace of what dpkg would have done if invoked (even this would be great...). But for the moment I think the list Inst/Conf/Rem will be enough. The real list of dpkg commands can be obtained (not in simulation mode) with the debug variable: Debug::pkgDPkgPM=true In the long term maybe the correct solution to all this mambo-jumbo would be to implement the packageManager bindings as a virtual class with a default on dpkg as it is now, but giving the possibility to override from the python side the Install/Configure/Remove/Go functions in order to hack into the pkgmanager algorithm cleanly. I'm not sure this is possible given the current architecture... As it is the OrderList class will allow to easily reimplement the backend and in theory to completely bypass the apt-pkg/deb/dpkgpm.cc and perform the installation via another package manager, say rpm... thanks again for your great support. pietro -- ---- http://en.wikipedia.org/wiki/Posting_style -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org