Re: Multiarch file overlap summary and proposal
Carsten Hey <email@example.com> writes:
> * Russ Allbery [2012-02-16 14:55 -0800]:
>> Every file that differs has to be fixed in the current multi-arch plan.
>> Documentation that contains its build date is going to need to be split
>> out into a separate -docs package.
> I doubt that ftpmaster would be happy about -doc packages that contain
> just a few small man pages.
I think they'll be okay with it when it's the cost of reasonable
I feel fairly strongly that it isn't sane to have a file overlap when the
file doesn't match. You then lose the error detection when there are real
problems, and I don't trust any of us, myself included, to correctly tag
files where it doesn't matter.
On this front, I agree with Guillem: some amount of package splitting is
fine, and package splitting instead of additional complexity, like tagging
files that are allowed to vary, looks like a good tradeoff to me. The
splitting that I'm worried about is where the files are tightly coupled,
which is not the case for development man pages that are now in -dev
> debianutils uses a special make target 'prebuild' in debian/rules to
> update build system related files and PO files before the actual source
> package is built.
> This basic idea also could be used to build problematic documentation
> files on the maintainers computer before he/she builds the package. The
> other targets would then install the prebuilt documentation into the
> package without the need to build it first. A proper dependency on
> debian/$prebuilt_doc could ensure that maintainers do not forget to run
> debian/rules prebuild.
> If maintainers choose to use such a target, suggesting a common name for
> it in the developers reference could be reasonable.
That's an interesting idea. That's very similar to what I already do as
upstream (I build POD-generated man pages from my autogen script, and in
Debian packaging don't bother to regenerate them).
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>