[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