On Wed, Sep 30, 2009 at 20:10 +1000, Ben Finney wrote:
> Wolodja Wentland <wentland@cl.uni-heidelberg.de> writes:
> If the distribution is done using Python's Distutils, then this should
> be configured by upstream: the configuration of ‘setup.py’ should
> include all files for the ‘sdist’, but deliberately omit the test suite
> and its data from installation.
Thanks for the explanation!
A short question though: Running the tests would entail that all
python-modules used by any given library or application would end up as
build dependencies of the package.
The dependencies of the application in question here are very modest
(python-progressbar) but this could be problematic if the test suite
requires a lot of other modules or even running and configured services
(DB, Web server, ...). How is this usually handled?
> > Furthermore it also installs application data into
> > PREFIX/share/foo/data. The data is unlikely to change, but could be
> > replaced by newer versions whenever the system administrator decides
> > to do so. Is '/usr/share/foo/data' correct for data like this?
> Yes. Newer package releases can of course replace files installed by
> older releases of the package (exception: conffiles), and for files that
> don't change during the lifetime of a particular release,
> ‘/usr/share/foo/’ is correct.
> You might want to consult the latest versions of FHS and Debian Policy
> to get more details on the appropriate places for files by their
> intended purpose.
I already read the FHS and am unsure whether '/usr/share/foo' or
'/var/lib/foo' is the appropriate place. There might even be a better
one :-)
The data is not necessarily needed by the application/library but
significantly enhances its functionality. It is therefore packaged by
upstream as an additional foo-data distribution and will be packaged in
Debian as an additional package.
The data *might* change during the lifetime of the release which is
unlikely but possible. A system administrator might want to update these
data files without having a new release from upstream. I think this is
unlikely to happen but it is a possible scenario.
/var/lib/foo-data does not seem to be the appropriate place for these
files as the data is not state information that is modified while the
application/library is used.
/usr/share/foo-data looks more promising if it were not for the fact
that an administrator could want to update these files without having a
corresponding upstream release of foo-data.
My intuition tells me that /usr/share/foo-data is the appropriate place
and that updated information should be considered a bug which, once
filed and processes, will trigger a new release of foo-data. Is this
more or less correct?
kind regards
Wolodja Wentland
Attachment:
signature.asc
Description: Digital signature