Approaching non-integratable software, was: What to do with (packages like) Blender?
[ moving discussion to -project. Please follow up on -devel if you are
contributing to the technical discussion and -project for the project
wide parts ]
Cyril Brulebois <firstname.lastname@example.org> writes:
> It's been a while and I'm now really wondering what to do with
> Blender. So that everyone can understand, I'm going to try and sum up
> what I'm facing.
It seems to me that blender is not unique in this regard. There is more
software than just blender that prefers to not be integrated into a
distribution properly, but rather prefers to retain exact control of
(external) libraries that are being included into their source and
binaries. Another characteristic is that they focus on binary
redistribution, and frown upon users that grab the source and compile
blender is surely not alone. Other prominent, yet unpackaged pieces of
software would be handbrake , or XBMC. For handbrake the
"solution" so far has been to not package it at all , xbmc is having
a hard time working on the source to use system libraries.
I think it would be sad to not include such packages at all. Knowing
proper integration into Debian as distribution is not going to work, how
about integrating them as "add-on" software? I imagine the following
- software gets installed into /opt, so that file conflicts are less
likely and the software status is visible to the users
- packages go to an special section of the archive "extra". That
section would be similar to "contrib": autobuilt, PTS and BTS
coverage, no security support .
- package can easily be moved to "main" after it has matured to use
In some ways, this extra repository can be seen as staging or preview
repository. We wouldn't need to provide the tedious and laboratory QA
tasks concerning security and integration efforts, but could still
provide our users with such software.
Reinhard Tartler, KeyID 945348A4