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

Re: Multiarch file overlap summary and proposal



Josselin Mouette <joss@debian.org> 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
>>    failing.
>
> 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
solution.

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

MfG
        Goswin


Reply to: