Re: Multiarch file overlap summary and proposal

2012-02-17 Thread Carsten Hey
* David Kalnischkies [2012-02-17 17:20 +0100]: > Why would it be intuitive to add a specific value for the arch attribute with > apt-get install foo # arch |= native > but remove all values of the attribute with > apt-get remove foo# arch &= ~all-architectures > ? We had a similar discussion

Re: Multiarch file overlap summary and proposal

2012-02-17 Thread Carsten Hey
* David Kalnischkies [2012-02-17 14:15 +0100]: > You generously left out the paragraph describing how APT should > detect that the package foo is in fact a library ... My impression was that you think very library centric. All I wrote was (in other words), that we should consider non-library pack

Re: Multiarch file overlap summary and proposal

2012-02-17 Thread Carsten Hey
* Russ Allbery [2012-02-16 14:55 -0800]: > Carsten Hey writes: > > There are still files that differ that do not need to be fixed, for > > example documentation that contains it's build date. > > Every file that differs has to be fixed in the current multi-arch plan. >

Re: Multiarch file overlap summary and proposal

2012-02-16 Thread Carsten Hey
* Russ Allbery [2012-02-16 10:43 -0800]: > * Users who want to co-install separate architectures will immediately > encounter a dpkg error saying that the files aren't consistent. This > means they won't be able to co-install the packages, but dpkg will > prevent any actual harm from happeni

Re: Multiarch file overlap summary and proposal

2012-02-16 Thread Carsten Hey
* David Kalnischkies [2012-02-16 03:59 +0100]: > On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote: > >>>   it needs to find and remove foo:* foo:all (or foo:any) instead of foo:* would save the need to quote it. > > Actually, why would that be the behavior?  Why would dpkg --purge foo not > > j

Re: Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)

2012-02-11 Thread Carsten Hey
* Aron Xu [2012-02-09 01:22 +0800]: > Some packages come with data files that endianness matters, and many > of them are large enough to split into a separate arch:all package if > endianness were not something to care about. ... Debian Policy, begin of section 5.6.8: | Depending on context and th