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

Bug#623485: python-apt: please add bindings pkgOrderList



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



Reply to: