Re: Ok to use upstream doumentation as-is (i.e. not regenerate)?
Jonas Smedegaard <dr@jones.dk> writes:
> I have noticed several times package changes like the following (from
> cairomm entering testing today):
>
> * debian/control:
> - Drop build dependencies on doxygen and graphviz, since upstream
> now ships the generated documentation
>
>
> Feels wrong to me to redistribute when e.g. html files clearly are not
> the preferred form of editing for upstream.
To me, that doesn't sound all that troubling: we do use other generated
files that upstream ships more often than not: configure, Makefile.ins -
and so on. Though, those are rarely shipped in the binary package, but
still: we do not build-depend on the tools that generate these.
Technically, upstream could do anything in those files, write them by
hand instead of generating from configure.ac, and include that in the
distributed tarball, potentially under a non-free license.
In any case: even if upstream shipts generated content, as long as the
source is shipped aswell, all is fine and well, in my opinion. The
_source_ needs to be in the preferred form of modification. If it
contains generated files aswell, that doesn't matter all that much: the
source is still there. You just don't have to use it, if the result
would be the same anyway.
> Or can some of you enlighten me with your personal reasoning for your
> own packaging style?
My personal preference is to trust upstream to not be a moron, and if he
makes my job easier, cutting build-dependencies down, I'm all for it.
(Provided that said action does not cause unwanted side effects, like
the documentation being out of date, because upstream forgot to
regenerate them before distribution - but that falls under the "upstream
to not be a moron" above ;)
--
|8]
Reply to: