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
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
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
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
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
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.
>>
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
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
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.
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
10 matches
Mail list logo