Changes between Initial Version and Version 1 of Ticket #1594


Ignore:
Timestamp:
01/27/18 19:28:29 (6 years ago)
Author:
geofft
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1594 – Description

    initial v1  
    77In practice, for people just using a single arch, it doesn't matter much. But I think the big case this affects is converting a Debathena machine in-place from one architecture to another (e.g., i386 to amd64). So long as `debathena-workstation` isn't `Multi-Arch: all`, the package is broken unless _all_ of its dependencies are installed from the native architecture, so switching the machine's native architecture gets a lot more complicated immediately for no good reason. 
    88 
    9 See [https://github.com/sipb/config-package-dev/pull/2#issuecomment-361025694 my comment on config-package-dev#2] and the links in that PR, notably DebianWiki:Hints#set_Multi-Arch:_foreign, for more details. 
     9See [https://github.com/sipb/config-package-dev/pull/2#issuecomment-361025694 my comment on config-package-dev#2] and the links in that PR, notably [https://wiki.debian.org/MultiArch/Hints#set_Multi-Arch:_foreign MultiArch/Hints "set Multi-Arch: foreign"] on the Debian wiki, for more details. 
    1010 
    1111We should in theory go through all `Arch: all` Debathena packages, make sure they're not doing anything weird with compiling things in postinsts or depending on arch-specific libraries. (Most Debathena metapackages or config packages should not care about libraries; those that do, like debathena-athena-libraries, should be `Architecture: any` anyway so that you can install both sets of libraries if you want.)