[Pkg-blender-maintainers] Deep modifications of the blender wrapper

[Cyril Brulebois]

Hi,

in addition to various cleanup in the package (in particular cleaning
the rules file, making the package FHS compliant), I've modified the
wrapper as follows.

Background first: Until now, each time blender is started, all scripts
available in /usr/lib/blender/scripts were symlinked from
~/.blender/scripts. Issues:
 1. Release after release, scripts get renamed, or even deleted. Which
    means a bunch of broken symlinks.
 2. More importantly, let's say a user installs manually a foobar.py
    scripts in his personal directory. If a script with the same name
	(but not necessarily the same purpose, content, version, etc.) is
	included in a further release of Blender, the user one gets
	overriden, which means data loss.

To solve both issues, I've modified the wrapper to do the following.
 1. It is supposed that the structure of the scripts directory is flat:
	every script is in the ~/.blender/scripts directory, no
	subdirectories.
 2. If is is detected that a migration a needed, every file in this
	directory gets evaluated. If it is a symlink to
	/usr/{lib,share}/blender/scripts*, it gets removed. Otherwise, it is
	kept.
 3. The current version of the Debian package (dpkg -l blender|grep ^ii)
    is written in ~/.blender/REVISION, so that one can compare a version
    with the one used during the last Blender startup. This way, one can
    tell when a migration is needed, using dpkg --compare-versions, as
	done in 1., so that 2. can be skipped.
 4. In every case, all items of /usr/share/blender/scripts/* are
    considered. If such an item doesn't exist already, a symlinked is
	created. If it does, nothing is attempted. One could think of
	creating a directory where one could move those files/directories,
	but then what happens if the target directory/item already exists?
	Too much troubles I think, for the rare cases where the user will
	have a directory or a file named “blender” or “sunflow”.

To sum up, it seems to ensure:
 1. Data loss can no longer happen.
 2. There's no dead symlink (at least due to the previous behaviour of
    the wrapper script) to *.py(c) files anymore.
 3. Scripts are kept sorted by directory/package:
      ~/.blender/scripts/blender -> /usr/share/blender/scripts/blender
	  ~/.blender/scripts/sunflow -> /usr/share/blender/scripts/sunflow
    etc.

What lacks is the automatical removal of dead directory symlink, e.g. if
sunflow is there at some point (and the symlink created), and then later
removed. That kind of check can be added later, but that doesn't sound
really needed right now, I'd better make sure that the current script
does its job. As far as I can tell after some tests, it looks like, but
one never knows. :)

Oh, and if someone wonders why I'm checking for the need of a
transition, it's to avoid hammering the file systems when there are a
bunch of scripts, like I believe many Blender users can happen to have.
It also helps keeping track of when this or that change happens, without
having to look for the changelog.

Thoughts?

To check the package, quick way:

,---[ Summary ]---
| git-clone ssh://$you@git.debian.org/git/collab-maint/blender.git blender.git
| cd blender.git
| uscan --force-download  # fetch the tarball
| debuild -us -uc -i      # -i to build without considering $VCS files, that
|                         # is: ignoring .git, .svn, and so on.
`---

Besides that, I believe it is somehow ready for an upload. I'll
doublecheck the wrapper stuff with real systems (I'm faking an upgrade
at the moment) within a few days, and will then consider uploading
sunflow (another mail will follow about this renderer).

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/20080112/316a63bc/attachment.pgp