Russ Allbery r...@debian.org writes:
Goswin von Brederlow goswin-...@web.de 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
On Sun, Feb 12, 2012 at 08:00, Carsten Hey cars...@debian.org wrote:
* 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. ...
* 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 the
Ian Jackson ijack...@chiark.greenend.org.uk 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
Goswin von Brederlow writes (Re: Please test gzip -9n - related to dpkg with
multiarch support):
Ian Jackson ijack...@chiark.greenend.org.uk 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
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Goswin von Brederlow writes (Re: Please test gzip -9n - related to dpkg with
multiarch support):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
One thing which no-one yet seems to have suggested is to have
multiarch:same packages
Goswin von Brederlow goswin-...@web.de 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
On Tue, Feb 07, 2012 at 10:49:23PM +, Ben Hutchings wrote:
But it's worse than this: even if dpkg decompresses before comparing,
debsums won't (and mustn't, for backward compatibility). So it's
potentially necessary to fix up the md5sums file for a package
installed for multiple
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/07/2012 11:04 PM, Neil Williams wrote:
I'm not convinced that this is fixable at the gzip level, nor is it
likely to be fixable by the trauma of changing from gzip to
something else.
while the original point of not considering compressors
On Wed, 2012-02-08 at 07:57 +, Lars Wirzenius wrote:
On Tue, Feb 07, 2012 at 10:49:23PM +, Ben Hutchings wrote:
But it's worse than this: even if dpkg decompresses before comparing,
debsums won't (and mustn't, for backward compatibility). So it's
potentially necessary to fix up the
On Tue, Feb 07, 2012 at 10:04:04PM +, Neil Williams wrote:
Maybe the way to solve this properly is to remove compression from the
uniqueness check - compare the contents of the file in memory after
decompression. Yes, it will take longer but it is only needed when the
md5sum (which already
On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
Well, it does mean that you might be lacking important information
because the other changelog wouldn't be present on the system.
While the implicit Replaces seems the easy way out, it just seems even
more fragile than the shared files
On Wed, 2012-02-08 at 17:29:22 +0100, Mike Hommey wrote:
If you remove the shared files approach, how do you handle files like
lintian overrides, reportbug presubj and scripts, etc. ?
The same principle that applies to all dpkg output to avoid ambiguity
would apply everywhere, whenever there's
Guillem Jover writes (Re: Please test gzip -9n - related to dpkg with
multiarch support):
On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
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
Ian Jackson wrote:
Another relevant question is whether there are other files that are
shared, and which don't want to move, besides ones in /usr/share/doc.
One example is header files in /usr/include, from -dev packages. In
the simple examples I've seen, putting them in /usr/include/triplet,
I want to speak up about endianness of data files, this is a
suggestion but not a flaw which I just want to discover the
possibility of improvement to current status by the chance of
implementing Multi-Arch in Debian.
Some packages come with data files that endianness matters, and many
of them
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 about. AFAIK some maintainers
are not aware of endianness issues in their packages
On Wed, Feb 08, 2012 at 05:56:11PM +0100, Guillem Jover wrote:
On Wed, 2012-02-08 at 17:29:22 +0100, Mike Hommey wrote:
If you remove the shared files approach, how do you handle files like
lintian overrides, reportbug presubj and scripts, etc. ?
The same principle that applies to all dpkg
On Thu, Feb 9, 2012 at 01:35, Simon McVittie s...@debian.org 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 about. AFAIK
Guillem Jover guil...@debian.org writes:
On Wed, 2012-02-08 at 13:19:17 +, Ian Jackson wrote:
Well, it does mean that you might be lacking important information
because the other changelog wouldn't be present on the system.
While the implicit Replaces seems the easy way out, it just
On Wed, Feb 08, 2012 at 11:56:06AM -0800, Russ Allbery wrote:
Riku Voipio riku.voi...@iki.fi writes:
On Wed, Feb 08, 2012 at 05:56:11PM +0100, Guillem Jover wrote:
The same principle that applies to all dpkg output to avoid ambiguity
would apply everywhere, whenever there's a “Multi-Arch:
On Wed, Feb 08, 2012 at 10:22:17AM +, Neil Williams wrote:
After all, this is how cross/foreign architecture packages have
*always* been handled in Debian via dpkg-cross. Nothing in /usr/share/
matters for a cross package created by dpkg-cross (with the possible
exception of
Steve Langasek vor...@debian.org writes:
The unfounded assumption here is that you will always install a
foreign-arch M-A: same package together with the native-arch version.
If I install libaudio2:i386 because I want to play a game that's only
available as a 32-bit binary and has this lib as
On Wed, Feb 08, 2012 at 04:55:02PM -0800, Russ Allbery wrote:
Steve Langasek vor...@debian.org writes:
The unfounded assumption here is that you will always install a
foreign-arch M-A: same package together with the native-arch version.
If I install libaudio2:i386 because I want to play a
Steve Langasek vor...@debian.org writes:
On Wed, Feb 08, 2012 at 04:55:02PM -0800, Russ Allbery wrote:
Steve Langasek vor...@debian.org writes:
The unfounded assumption here is that you will always install a
foreign-arch M-A: same package together with the native-arch version.
If I install
On Tue, 07 Feb 2012 19:11:16 +0100
Michael Biebl bi...@debian.org wrote:
On 07.02.2012 18:07, Joey Hess wrote:
Neil Williams wrote:
I'd like to ask for some help with a bug which is tripping up my tests
with the multiarch-aware dpkg from experimental - #647522 -
non-deterministic
Neil Williams codeh...@debian.org writes:
Maybe the way to solve this properly is to remove compression from the
uniqueness check - compare the contents of the file in memory after
decompression. Yes, it will take longer but it is only needed when the
md5sum (which already exists) doesn't
On Tue, Feb 07, 2012 at 10:04:04PM +, Neil Williams wrote:
On Tue, 07 Feb 2012 19:11:16 +0100
Michael Biebl bi...@debian.org wrote:
On 07.02.2012 18:07, Joey Hess wrote:
Neil Williams wrote:
I'd like to ask for some help with a bug which is tripping up my tests
with the
On Tue, 07 Feb 2012, Ben Hutchings wrote:
But it's worse than this: even if dpkg decompresses before comparing,
debsums won't (and mustn't, for backward compatibility). So it's
Maybe you can switch to sha256 and add the new functionality while at
it? Detect which mode (md5sum raw, sha256
29 matches
Mail list logo
