Re: Multiarch file overlap summary and proposal
Russ Allbery <rra@debian.org> writes:
> Carsten Hey <carsten@debian.org> 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
> multiarch.
>
> 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
> packages.
+1.
I find the argument about past experience with splitting packages and
upstream later changing files so they become arch dependent convincing
in this regard. Refcounting and no exception for file differences seems
to be the best way.
>> 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).
Indeed. Another +1.
You are probably not the only one doing something like this. Who else
does this? What automatism do you have in your debian/rules to help?
Lets see if we can get a good set of examples to work out some
recommendations.
MfG
Goswin
Reply to: