Re: Multiarch file overlap summary and proposal
Josselin Mouette <email@example.com> writes:
> Le lundi 13 fÃ©vrier 2012 Ã 22:43 -0800, Russ Allbery a Ã©crit :
>> There's been a lot of discussion of this, but it seems to have been fairly
>> inconclusive. We need to decide what we're doing, if anything, for wheezy
>> fairly soon, so I think we need to try to drive this discussion to some
>> concrete conclusions.
> Thank you very much for your constructive work.
>> 3. Generated documentation. Here's where I think refcounting starts
> So we need to move a lot of documentation generated with gtk-doc or
> doxygen from -dev packages to -doc packages. But it really seems an
> acceptable tradeoff between the amount of work required and the
> cleanness of the solution.
>> Does this seem comprehensive to everyone? Am I missing any cases?
> Are there any cases of configuration files in /etc that vary across
> architectures? Think of stuff like ld.so.conf, where some plugins or
> library path is coded in a configuration file.
Generally conffiles in library packages is a violation of policy
8.2. They would create a file overwrite conflict if the SONAME
changes. Putting the conffile into the -common package is a good
There are some exceptions where the conffiles are version qualified.
E.g.: libgtk2.0-0: /etc/gtk-2.0/im-multipress.conf
For conffiles that vary across architectures the path or name must
include the multiarch triplet.
E.g: libc6: /etc/ld.so.conf.d/x86_64-linux-gnu.conf
(Note: this is actualy a violation of policy 8.2 and needs to be fixed
when we get a libc7).