[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Unit tests and application data



Wolodja Wentland <wentland@cl.uni-heidelberg.de> writes:

> 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.

The system administrator *might* decide to change any file they like;
that doesn't affect the decision of where the operating system should
install those files. The question is how those files are treated by the
operating system.

If the files are static data that the programs should not modify (with
the already noted exception of package installation and upgrade), then
‘/usr/share/foo/’ is a good place for them.

> /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.

Correct, ‘/var/’ is not the right place for static data files.

> 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?

You've said that the ‘foo-data’ package will be data solely intended for
use with the ‘foo’ package. In that case, they should not be installed
to ‘/usr/share/foo-data/’ since that implies they're conceptually
separate from ‘foo’. Rather, ‘/usr/share/foo/’ seems the right place to
me.

-- 
 \     “Yesterday I parked my car in a tow-away zone. When I came back |
  `\                      the entire area was missing.” —Steven Wright |
_o__)                                                                  |
Ben Finney

Attachment: pgp8LFSlmKMaj.pgp
Description: PGP signature


Reply to: