The support to various package managers has been achieved using a virtual class. Virtual classes simply provide objects interface, as they define all methods, but not implement them. They are used to supply late-binding feature which means that a new instance of any class can be created and assigned to a virtual object with the same interface while the process is running. Then the programmer can access all methods of the new object as they belong to the virtual one. In PackageFS a real class which holds these overriding methods is the one that (sometimes) replaces the package manager or, if required, invokes it to accomplish many operations on packages.
The interface is provided by PkgManager, that should act as a bridge between PKGFS library functions and a kind of general package management. This last has been designed to deal mostly with package managers cache, because of the possibility to retrieve many information from it. Distribution package manager should be invoked only if necessary, and only after PackageFS itself has done some checks. This way, duplication of efforts in developing entirely a new package manager is avoided. We remember that either in LUFS or in FUSE, PackageFS runs as a daemon process, so it should neither request input nor give output.
Is the virtual class really needed to support various package managers? If we consider that a distribution has only one package management software, we could set distribution type at compile-time. Virtual classes, as we said, provide dynamic overriding facility at run-time, so that they may slow down the whole application. However, there are many reasons that led PackageFS to such a solution, as following: