[Pkg-blender-maintainers] Possible data loss, and sunflow exporter/renderer

[Cyril Brulebois]

Hi,

I'm currently maintaining Sunflow, which is a (java-based…) renderer.
With it comes an exporter for Blender (Blender scene -> Sunflow files)
so that it is possible to use Sunflow as a renderer for Blender scenes
(a bit like Yafray although the integration isn't as good as Yafray's).

So that other packages can ship Blender scripts, I've modified the
wrapper so that it looks under /usr/share/blender/scripts/ and symlinks
every directory there inside ~/.blender/scripts.

I discovered today that bpydata has to be in that ~/blender/scripts
directory so that data is available from scripts as well, so I decided
to use the following symlink:
  ~/.blender/scripts/bpydata -> ~/.blender/bpydata.

My main concern is that upon upgrades (new upstream release, which
version number is written in the VERSION file), the ~/.blender/bpydata
is “updated” using a “cp” call (from /usr/share/blender/bpydata). It
looks to me that it can lead to data loss (user customization). I have
to admit that no user complained until now, but still, I'm quite
uncomfortable with that.  Maybe we could preventively move
~/.blender/bpydata to ~/.blender/bpydata-$version where $version is the
content of the VERSION file? That way, users will be able to get back
their data if needed, but also will get the new data from the new
upstream release, by default. If someone reports a bug, it is sufficient
to point the reporter to that mechanism and it should be possible to get
the wanted file(s) back from that directory, don't you think? Not to
mention that this directory is only a few kB.


Now, back to Sunflow. It consists of a Java-based core, but also ships
exporters for Blender and for Maya. Currently I'm not even trying to
build the Maya one, which isn't complete at all, and probably not that
useful on Debian (until someone complains, I guess). My main point of
interest is to fetch regularly updates of the Blender exporter through
svn. That's why I scripted that update, refreshing a quilt patch,
extracting subversion revisions, so as to automatically create an
adapted changelog entry (either the patch is created or refreshed). Only
runtime tests and copyright review remain (there are a bunch of authors
working on this script). I'm wondering whether it's OK to keep on using
the following scheme: 0.07.2.dfsg-N, incrementing N when I refresh the
patch (like once per month or so, depending on the number of revisions
that happened, and the content of the changelog). One could think of
using 0.07.2.dfsg+rXYZ, but that'd mean uploading a new tarball
everytime, instead of just putting a (new or refreshed) patch in the
diff. Do you think that what I plan to do (the former way) is somehow
bad practice, or should I just go ahead? If it's just fine, maybe one of
you could sponsor it?

Cheers,

-- 
Cyril Brulebois
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-blender-maintainers/attachments/20080113/42941710/attachment.pgp