[Engine-devel] Things to be done to support Ubuntu hosts

Alon Bar-Lev alonbl at redhat.com
Wed Nov 20 12:56:56 UTC 2013



----- Original Message -----
> From: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt at kohlvanwijngaarden.nl>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Antoni Segura Puimedon" <asegurap at redhat.com>, "Zhou Zheng Sheng" <zhshzhou at linux.vnet.ibm.com>, "engine-devel"
> <engine-devel at ovirt.org>
> Sent: Wednesday, November 20, 2013 2:49:17 PM
> Subject: Re: [Engine-devel] Things to be done to support Ubuntu hosts
> 
> On Wed, Nov 20, 2013 at 07:03:05AM -0500, Alon Bar-Lev wrote:
> > Antoni Segura Puimedon wrote:
> > > Would it make sense to leverage packagekit to abstract away the distro
> > > packaging differences? http://www.packagekit.org/pk-using.html
> >
> > Not really... as it is egg and chicken...
> > How do I install this package on vanilla host?
> 
> Plus it's still likely that package names differ.

This is another issue, which I don't think that package manager abstraction solves.
But it is easy to solve by adding name mapping within current host-deploy implementation.

> I still think some
> abstraction here could help. Try some autodetection on package managers
> and prefer packagekit, then try yum, then apt-get, then aptitude for
> example.

It is not that easy... we currently use the yum api to be able to participate in yum transaction, we also require to manage the version lock legacy hack and we need to know before installation if we can revert to previous version.

So it is not that simple to use abstraction, well, until our product will behave better, for example it will support previous database schema so that no need to run setup for upgrade and mess up with packaging.

For now, I truly think that it is easier to just execute apt-get or any other tool, otopi already built under that assumption.

> 
> > And... it does not support gentoo as far as I can see :)))
> 
> As a Gentoo user, I don't find this suprising. The whole concept of
> USE-flags looks hard to abstract away and still be compatible with all
> the other distributions. Especially if there's USE-dependencies in the
> mix.
> 



More information about the Devel mailing list