2014-07-12 14:00 GMT+04:00 Richard W.M. Jones <rjones(a)redhat.com>:
It depends entirely on what the Linux kernel and tools can do. If
there are properly maintained Linux tools for resizing BSD slices,
then it should be no problem to add this.
Compare with 'ntfsresize', where ntfs-3g exists and is well-maintained
and available in the majority of Linux distros.
As i see parted have ability to work with bsd slices, also linux
kernel have bsd partition support. Bud i don't know about resize file
system.
> I think that golang bindings need separate repo, may be
autogenerate
> bindings and push resulted files to separate github repo.... In this
> case peaples can do go get
github.com/libguestfs/go-libguestfs and
> have a package. And build it with or without CGO_ENABLED (static or
> dynamic). But in case of autogenerated binding i don't know how to
> write docs and keep it sync with code...
The trouble with a separate repository is that it would quickly go out
of date compared to the current API. That's why we strongly prefer to
keep the bindings in tree (and of course generated, not hand-written).
But why? As i understand binding updated when new release comes, not
the big problem generate code go bindings and upload it to github, or
some git repo, got get able to install package from git repos...
Can we not build some kind of tarball? A similar situation was
proposed for accepting libguestfs bindings into Python pypi.
Tarball not suitable for go... Also for docs - you can create in repo
file doc.go and provide interfaces/function names with extracted
portion of comments from headers. This is enough to generate some docs
about exiting functions...
--
Vasiliy Tolstov,
e-mail: v.tolstov(a)selfip.ru
jabber: vase(a)selfip.ru