Re: Please test gzip -9n - related to dpkg with multiarch support

2012-02-09 Thread Goswin von Brederlow
Ian Jackson writes: > Russ Allbery writes ("Re: Please test gzip -9n - related to dpkg with > multiarch support"): >> Another possible solution is to just give any package an implicit Replaces >> (possibly constrained to /usr/share/doc) on any other package with the >> same name and version and

Re: Endianness of data files in MultiArch

2012-02-09 Thread Goswin von Brederlow
Aron Xu writes: > On Thu, Feb 9, 2012 at 01:35, Simon McVittie wrote: >> On 08/02/12 17:22, Aron Xu wrote: >>> 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

Re: Please test gzip -9n - related to dpkg with multiarch support

2012-02-09 Thread Ian Jackson
Goswin von Brederlow writes ("Re: Please test gzip -9n - related to dpkg with multiarch support"): > Ian Jackson writes: > > One thing which no-one yet seems to have suggested is to have > > multiarch:same packages put the changelog in a filename which is > > distinct for each architecture. (It

Re: Endianness of data files in MultiArch

2012-02-09 Thread Guillem Jover
On Thu, 2012-02-09 at 13:52:34 +0100, Goswin von Brederlow wrote: > Aron Xu writes: > > This looks not very nice, because we need to maintain a list of > > architectures in debian/control, and when new architectures are added > > the package is potentially broken. > > If endian dependend data is

Re: Please test gzip -9n - related to dpkg with multiarch support

2012-02-09 Thread Goswin von Brederlow
Ian Jackson writes: > Goswin von Brederlow writes ("Re: Please test gzip -9n - related to dpkg with > multiarch support"): >> Ian Jackson writes: >> > One thing which no-one yet seems to have suggested is to have >> > multiarch:same packages put the changelog in a filename which is >> > distinc

Re: Endianness of data files in MultiArch

2012-02-09 Thread Goswin von Brederlow
Guillem Jover writes: > On Thu, 2012-02-09 at 13:52:34 +0100, Goswin von Brederlow wrote: >> Aron Xu writes: >> > This looks not very nice, because we need to maintain a list of >> > architectures in debian/control, and when new architectures are added >> > the package is potentially broken. >>

Re: Please test gzip -9n - related to dpkg with multiarch support

2012-02-09 Thread Russ Allbery
Goswin von Brederlow writes: > Changing the name in the package would break tools that rely on the name > (like packages.debian.org extracting the Changelog). Also ugly. We control the tools; we can change the tools. Multiarch is a big deal. We weren't going to get through this without changing

dpkg behavior while changing a foreign package from arch:any to arch:all (and v.v.)

2012-02-09 Thread David Kalnischkies
Hi list of dpkg-glory, Sometimes packages change their arch from arch:any to arch:all (or v.v.). This used to be no problem for packages where any was the native arch and this is still the case, but if it is a foreign arch dpkg refuses to install the new arch:all version with the following error

Re: Endianness of data files in MultiArch

2012-02-09 Thread Aron Xu
On Thu, Feb 9, 2012 at 20:52, Goswin von Brederlow wrote: > > It should be possible to build a converter or generator that can output > either endianess. So you could have a single arch:all package with both > /usr/share/$package/data/{be,le} in it or to generate the right > endianness on install.

Re: dpkg behavior while changing a foreign package from arch:any to arch:all (and v.v.)

2012-02-09 Thread Raphael Hertzog
On Fri, 10 Feb 2012, David Kalnischkies wrote: > I am not sure through if this is really a bug in dpkg, given that arch:all is > to be interpreted as arch:native in multiarch, so on an amd64 system a > flip from arch:amd64 to arch:all is not really a flip (and therefore works) > while arch:i386 to