[Pkg-ganeti-devel] [SCM] Ganeti packaging branch, for-review, updated. debian/2.7.0-1-23-gf0feb68

Iustin Pop iusty at k1024.org
Mon Jul 15 19:49:30 UTC 2013


On Mon, Jul 15, 2013 at 01:07:57PM +0300, Apollon Oikonomopoulos wrote:
> Hi all,
> 
> I just pushed the final (?) set of changes, the most important of all 
> being the private/public module separation and the separate 
> python-ganeti-rapi package. Currently the public module includes the 
> RAPI client, the private module contains the rest of the public code.

Excellent!

> IMHO, this is the "proper" way to ship Ganeti, since all internal APIs 
> are not guaranteed to be stable. Furthermore, it allows us to 
> byte-compile the whole Ganeti code only for the default Python version, 
> while shipping the public components (RAPI) for all supported Python 
> versions.

Agreed :)

> There are a couple of rough edges though: First of all, any 3rd-party 
> applications using internal APIs will most likely stop working until 
> migrated to the private path, OTOH this could have happened anyway 
> because of internal API changes. Second, as this installation layout is 
> not directly supported by `make install', I had to hardcode executable 
> names in debian/rules in order to move them around. This is already done 
> for htools and ganeti-haskell and I can't say I like this duplication.

Hmm. I thought Guido changed the manual 'mv' to dh_movefiles? Would that
helper work here too, plus dh_symlinks?

> Anyway, this is more of a proof-of-concept. In my system it seems to 
> work, I haven't tested on a real cluster though.
> 
> Please share your opinion :-)

I don't have access to any clusters right now, but otherwise it's in a
good direction.

thanks,
iustin



More information about the Pkg-ganeti-devel mailing list