Simon McVittie left as an exercise for the reader:
> Sorry, I spend a lot of my work time immersed in this sort of thing and
> how it differs between distributions, so I tend to forget that most
> developers are able to stick to one distro and don't need to know this!
no offense at all, and thanks
On Thu, 08 Jun 2023 at 19:22:02 -0400, nick black wrote:
> Simon McVittie left as an exercise for the reader:
> > Debian-style multiarch or Fedora/Arch-style multilib is a much, much
>
> this is at least the second time you've drawn this distinction
> in this thread. for anyone else who, like me
On Sun, Dec 07, 2014 at 01:08:24AM +0100, Timo Weingärtner wrote:
> A short-term fix for the dpkg errors could be to express the conflicting
> loader paths with Conflicts: between the relevant libc6 packages.
Have multiarch conflicts/breaks been specified already? Sure, this would not be
the spec
On Sun, Dec 7, 2014 at 8:08 AM, Timo Weingärtner wrote:
> So I enabled architectures in dpkg, updated the package lists and tried
> installing libc6 packages for each architecture, but dpkg refused to unpack
> libc6:mipsel after libc6:powerpc had been installed, because both
> architectures use th
On Fri, 8 Aug 2014 16:41:22 +0100, Wookey wrote:
> +++ Joerg Desch [2014-08-08 05:38 +]:
> > Today I've read about Debians Multiarch capabilities for the first time.
> > Is it possible to use this technique to build deb packages of libraries
> > for the mingw crosscompile toolchain too?
>
>
+++ Joerg Desch [2014-08-08 05:38 +]:
> Today I've read about Debians Multiarch capabilities for the first time.
> Is it possible to use this technique to build deb packages of libraries
> for the mingw crosscompile toolchain too?
In principle, yes. In practice right now, no. Stephen Kitt ha
Am 28.06.2014 19:44, schrieb Osamu Aoki:
> Hi,
>
> The path for the arch dependent header file seems to have several options.
>
> 1) /usr/include//*.h
> 2) /usr/include///*.h
> 3) /usr/lib///include/*.h
>
> I would like to know rationale for each choice, especially between 2 and 3.
1) has th
On 28/06/14 18:44, Osamu Aoki wrote:
> The path for the arch dependent header file seems to have several options.
>
> 1) /usr/include//*.h
> 2) /usr/include///*.h
> 3) /usr/lib///include/*.h
The correct answer depends:
(a) what users are meant to #include (e.g. vs. )
(b) whether users are m
On Sun, Jun 29, 2014 at 02:44:21AM +0900, Osamu Aoki wrote:
> Hi,
>
> The path for the arch dependent header file seems to have several options.
>
> 1) /usr/include//*.h
> 2) /usr/include///*.h
> 3) /usr/lib///include/*.h
>
> I would like to know rationale for each choice, especially between
Le 2013-05-05 03:50, Adam Borowski a écrit :
On Sun, May 05, 2013 at 12:08:06AM +0200, Stéphane Glondu wrote:
As far as bootstrapping is concerned, the OCaml sources include
precompiled (bytecode) executables that are used in a first stage of
the
build process (i.e. ocaml doesn't build-depend
Le 05/05/2013 03:50, Adam Borowski a écrit :
> On Sun, May 05, 2013 at 12:08:06AM +0200, Stéphane Glondu wrote:
>> As far as bootstrapping is concerned, the OCaml sources include
>> precompiled (bytecode) executables that are used in a first stage of the
>> build process (i.e. ocaml doesn't build-d
On Sun, May 05, 2013 at 12:08:06AM +0200, Stéphane Glondu wrote:
> As far as bootstrapping is concerned, the OCaml sources include
> precompiled (bytecode) executables that are used in a first stage of the
> build process (i.e. ocaml doesn't build-depend on itself). So no need
> for cross-compilati
Le 18/04/2013 16:41, Matthias Klose a écrit :
> So what is the status for some runtimes/interpreters (would like to see some
> follow-up/corrections from package maintainers)?
> [...]
> - Lua, Ocaml, Haskell, Guile, ... ?
First, let me explain a few notions that will be useful to grasp the
situat
On Sat, 2013-05-04 at 06:36:31 +0200, Matthias Klose wrote:
> Am 19.04.2013 00:33, schrieb Guillem Jover:
> I think the full-multiarch support for python in
> > experimental should really be reverted.
>
> No. This is backward, and the wrong way to go forward.
Sorry, but the way to go forward is
Am 19.04.2013 00:33, schrieb Guillem Jover:
I think the full-multiarch support for python in
> experimental should really be reverted.
No. This is backward, and the wrong way to go forward. I do acknowledge that
there are issues with the current state of dpkg, but I'm not seeing how you are
plan
On Sun, Apr 21, 2013 at 02:42:32AM +0300, Uoti Urpala wrote:
> Should that "set of running architectures" be just "architecture"?
No. Some packages can have multiple "runing architecturs". The most
obvious case is M-A:same packages where you can install the same package
for multiple architectures.
Helmut Grohne wrote:
> You point out a limitation that I'd consider to be a feature. My
> proposal requires that every package has a single set of running
> architectures that has to apply to all code contained.
Should that "set of running architectures" be just "architecture"?
I think that after
On Sat, Apr 20, 2013 at 05:42:52PM +0300, Uoti Urpala wrote:
> Helmut Grohne wrote:
> > On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote:
> > > 3) P runs a script using system interpreter X, and depends on the
> > >interpreter environment supporting functionality provided by Q.
> > >
Helmut Grohne wrote:
> On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote:
> > 3) P runs a script using system interpreter X, and depends on the
> >interpreter environment supporting functionality provided by Q.
> >Q needs to work for the arch matching installed version of X.
>
>
On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote:
> It seems correct at first glance, but not enough to solve all the issues
> mentioned. Currently existing package relationships lack information
> that is necessary to do the right thing in all cases. Consider different
> kinds of depend
Helmut Grohne wrote:
> Barring any mistakes this appears like a possible solution to the
> problem. Did you spot anything obviously wrong? Any example where you
> don't see how to work it out?
It seems correct at first glance, but not enough to solve all the issues
mentioned. Currently existing pa
On Thu, Apr 18, 2013 at 04:41:35PM +0200, Matthias Klose wrote:
> - Ruby: Afaik, not yet started on multiarch.
Ruby 2.0 has multiarch support upstream. The Debian packaging is not
finished yet, but it will have multiarch.
I do not plan to multiarch 1.9.
--
Antonio Terceiro
signature.asc
Des
On Fri, Apr 19, 2013 at 12:33:07AM +0200, Guillem Jover wrote:
> As I pointed out on the debian-perl mailing list, after having
> discussed about multiarch support for perl, I don't think a fully
> multiarchified perl (nor at least python) should be uploaded to sid,
> as going full multiarch on the
On Fri, Apr 19, 2013 at 08:01:40AM -0700, Steve Langasek wrote:
> On Fri, Apr 19, 2013 at 05:26:41PM +0300, Niko Tyni wrote:
> > The modules aren't linked against libperl, it's
> > the other way around: libperl loads them at run time with dlopen(3).
> > They are effectively plugins in a private di
On Fri, Apr 19, 2013 at 05:26:41PM +0300, Niko Tyni wrote:
> On Thu, Apr 18, 2013 at 11:01:17PM -0700, Steve Langasek wrote:
> > On Thu, Apr 18, 2013 at 04:18:38PM +0100, Neil Williams wrote:
> > > I don't see a need to have the perl:i386 interpreter installed on amd64
> > > in order to build thir
On Thu, Apr 18, 2013 at 11:01:17PM -0700, Steve Langasek wrote:
> On Thu, Apr 18, 2013 at 04:18:38PM +0100, Neil Williams wrote:
> > I don't see a need to have the perl:i386 interpreter installed on amd64
> > in order to build third party i386 perl modules, the amd64 interpreter
> > should be fine
On Thu, Apr 18, 2013 at 04:41:35PM +0200, Matthias Klose wrote:
> So what is the status for some runtimes/interpreters (would like to see some
> follow-up/corrections from package maintainers)?
> - Perl: Afaik, Neil did prepare the interpreter to cross-build, and
>to co-install the runtime a
On Thu, Apr 18, 2013 at 04:18:38PM +0100, Neil Williams wrote:
> > - Third party modules for interpreters should be cross-buildable.
> >Many build systems for interpreter languages are written in the
> >interpreter language itself. So you do require the interpreter
> >for the build, an
On Thu, Apr 18, 2013 at 04:18:20PM +0100, Neil Williams wrote:
> On Thu, 18 Apr 2013 16:41:35 +0200
> Matthias Klose wrote:
>
> > - running a gdb:amd64 on i386 to debug 64bit binaries. This is the
> >reason for our current gdb64 package on i386, but it is missing the
> >support for the p
On 18 April 2013 19:13, Sergei Golovan wrote:
> Hi!
>
> On Thu, Apr 18, 2013 at 9:56 PM, Andrew Shadura wrote:
>>
>> Hello,
>>
>>
>> By the way, have you contacted Sergei on this?
>
> I saw the bugreports and I'm planning to start working on them after
> wheezy release.
>
Yeah there is no rush r
Hi!
[ I had pending warning about this on debian-devel before the release,
so this is a good way to do that. :) ]
On Thu, 2013-04-18 at 16:41:35 +0200, Matthias Klose wrote:
> There are maybe not many use cases where you do want to install an interpreter
> like python or perl for a foreign arch
Matthias Klose writes:
> There are maybe not many use cases where you do want to install an
> interpreter like python or perl for a foreign architecture, but there
> are some use case where such a setup makes sense.
One additional use case: I want to be able to do this in order to
cross-grade (t
On Thu, Apr 18, 2013 at 06:15:26PM +0100, Ian Jackson wrote:
> Goswin von Brederlow writes ("Re: multiarch and interpreters/runtimes"):
> > Co-installability of interpreters is generally not planed and would
> > have to be made as custom solutions, i.e. place the interpret
Hello,
On Thu, 18 Apr 2013 22:13:04 +0400
Sergei Golovan wrote:
> > To Sergei (added to Cc): I'd like to join the effort in packaging
> > Tcl/Tk and stuff, as I said before; but as you've been the most
> > active person on the team for quite some time I'm a bit hesitant
> > about interrupting th
Hi!
On Thu, Apr 18, 2013 at 9:56 PM, Andrew Shadura wrote:
>
> Hello,
>
>
> By the way, have you contacted Sergei on this?
I saw the bugreports and I'm planning to start working on them after
wheezy release.
>
> > Personally, I'm not yet convinced about this interpreter
> > multiarchification,
Hello,
On Thu, 18 Apr 2013 16:07:44 +0100
Dmitrijs Ledkovs wrote:
> > On 18 April 2013 16:41, Matthias Klose wrote:
> >> - Tcl/Tk: Wookey and Dimitrij did start on that in Ubuntu, patches
> >>are available in Debian bug reports.
> >>Currently the shared libraries are split out into sep
Goswin von Brederlow writes ("Re: multiarch and interpreters/runtimes"):
> Co-installability of interpreters is generally not planed and would
> have to be made as custom solutions, i.e. place the interpreter in
> /usr/lib/x86_64-linux-gnu/perl/ and provide /usr/bin/perl as
>
Le jeudi 18 avril 2013 à 16:41 +0200, Matthias Klose a écrit :
> - Python: co-installable runtime and development files, cross-buildability
>upstreamed for 2.7.4 and 3.3.1. There is a way to cross-build third
>party modules using distutils/setuptools. Packages are available in
>experim
On Thu, 18 Apr 2013 16:41:35 +0200
Matthias Klose wrote:
> - running a gdb:amd64 on i386 to debug 64bit binaries. This is the
>reason for our current gdb64 package on i386, but it is missing the
>support for the python based pretty printer.
>Installing gdb:amd64 on i386 in wheezy wil
On Thu, 18 Apr 2013 16:41:35 +0200
Matthias Klose wrote:
> - running a gdb:amd64 on i386 to debug 64bit binaries. This is the
>reason for our current gdb64 package on i386, but it is missing the
>support for the python based pretty printer.
>Installing gdb:amd64 on i386 in wheezy wil
On 18 April 2013 15:55, Andrew Shadura wrote:
> Hello,
>
> On 18 April 2013 16:41, Matthias Klose wrote:
>> - Tcl/Tk: Wookey and Dimitrij did start on that in Ubuntu, patches
>>are available in Debian bug reports.
>>Currently the shared libraries are split out into separate packages,
>>
On Thu, Apr 18, 2013 at 04:41:35PM +0200, Matthias Klose wrote:
> There are maybe not many use cases where you do want to install an interpreter
> like python or perl for a foreign architecture, but there are some use case
> where such a setup makes sense. For now I see this limited for architectu
Hello,
On 18 April 2013 16:41, Matthias Klose wrote:
> - Tcl/Tk: Wookey and Dimitrij did start on that in Ubuntu, patches
>are available in Debian bug reports.
>Currently the shared libraries are split out into separate packages,
>and are co-installable. Not yet tested if this enough
On 24 January 2013 04:56, Paul Johnson wrote:
> This is a multiarch issue I had not considered before. Have you seen
> it? I never wanted to be a "cross compiler", I really only want to
> build amd64. But I have some i386 libraries for a particular program
> (acroread).
>
I recently had to build
Paul Johnson gmail.com> writes:
> I've just learned that, if I build amd64 packages, I can't install
> them for testing because I've not also built the i386 packages.
Just test in cowbuilder --login.
> That's really inconvenient! I don't understand why there has to be a
> linkage between the sh
On 24/01/2013 12:56, Paul Johnson wrote:
> [...]
> I've just learned that, if I build amd64 packages, I can't install
> them for testing because I've not also built the i386 packages.
> [...]
> That's really inconvenient! I don't understand why there has to be a
> linkage between the shared library
Processing commands for cont...@bugs.debian.org:
> affects 637232 + release-notes
Bug #637232 [general] general: Multiarch breaks support for non-multiarch
toolchain
Bug #639214 [general] eglibc: changes to paths concerning crt1.o, crti.o and
crtn.o breaks building LLVM Trunk
Bug #644986 [genera
On Thu, Jun 14, 2012 at 09:22:43PM -0700, Russ Allbery wrote:
> "Theodore Ts'o" writes:
>
> > If a required package (such as e2fslibs, which is required by e2fsprogs)
> > provides multiarch support, then Lintian requires that the package have
> > a dependency on the package "multiarch-support"[1]
"Theodore Ts'o" writes:
> If a required package (such as e2fslibs, which is required by e2fsprogs)
> provides multiarch support, then Lintian requires that the package have
> a dependency on the package "multiarch-support"[1].
> However, this causes debcheck to complain because you now have a
>
Processing commands for cont...@bugs.debian.org:
> reassign 664257 debian-policy 3.9.3.1
Bug #664257 [general] multiarch tuples are not in the FHS
Bug reassigned from package 'general' to 'debian-policy'.
Ignoring request to alter found versions of bug #664257 to the same values
previously set
Ig
Processing commands for cont...@bugs.debian.org:
> retitle 664257 multiarch tuples are not in the FHS
Bug #664257 [general] multiarch tuples are not documented/defined
Changed Bug title to 'multiarch tuples are not in the FHS' from 'multiarch
tuples are not documented/defined'
> tags 664257 + ups
Goswin von Brederlow wrote:
> Sven Joachim writes:
>
>> On 2012-03-24 10:50 +0100, Adam Borowski wrote:
>>
>>> On Sat, Mar 24, 2012 at 09:48:58AM +0100, Sven Joachim wrote:
On 2012-03-24 04:04 +0100, Jay Berkenbilt wrote:
> One issue not covered is what to do if your package already bu
On Sat, 2012-03-24 at 18:37 +0100, Goswin von Brederlow wrote:
> Ben Hutchings writes:
>
> > On Sat, 2012-03-24 at 14:56 +0100, Goswin von Brederlow wrote:
> > [...]
> >> FYI: Since I have recieved no objections from ftp-master nor the release
> >> team the plan for ia32-libs now looks as follows
Ben Hutchings writes:
> On Sat, 2012-03-24 at 14:56 +0100, Goswin von Brederlow wrote:
> [...]
>> FYI: Since I have recieved no objections from ftp-master nor the release
>> team the plan for ia32-libs now looks as follows:
>>
>> Ia32-libs becomes a transitional package depending on ia32-libs-i3
On Sat, 2012-03-24 at 14:56 +0100, Goswin von Brederlow wrote:
[...]
> FYI: Since I have recieved no objections from ftp-master nor the release
> team the plan for ia32-libs now looks as follows:
>
> Ia32-libs becomes a transitional package depending on ia32-libs-i386.
> ia32-libs-i386 is a new tr
Sven Joachim writes:
> On 2012-03-24 10:50 +0100, Adam Borowski wrote:
>
>> On Sat, Mar 24, 2012 at 09:48:58AM +0100, Sven Joachim wrote:
>>> On 2012-03-24 04:04 +0100, Jay Berkenbilt wrote:
>>> > One issue not covered is what to do if your package already builds
>>> > 32-bit libraries on a 64-bi
On 2012-03-24 10:50 +0100, Adam Borowski wrote:
> On Sat, Mar 24, 2012 at 09:48:58AM +0100, Sven Joachim wrote:
>> On 2012-03-24 04:04 +0100, Jay Berkenbilt wrote:
>> > One issue not covered is what to do if your package already builds
>> > 32-bit libraries on a 64-bit system by building 32-bit ex
On Sat, Mar 24, 2012 at 09:48:58AM +0100, Sven Joachim wrote:
> On 2012-03-24 04:04 +0100, Jay Berkenbilt wrote:
> > One issue not covered is what to do if your package already builds
> > 32-bit libraries on a 64-bit system by building 32-bit explicitly and
> > packaging as lib32whatever.
>
> The
On 2012-03-24 04:04 +0100, Jay Berkenbilt wrote:
> I would like to do multiarch conversion for the icu packages. I
> understand the concept and the implementation, and I have looked at
> http://wiki.debian.org/Multiarch/Implementation. One issue not covered
> is what to do if your package alread
On Mar 04, Goswin von Brederlow wrote:
> > Also, why does refcounting have to be "perfect"?
> > What would break if it did not actually check that the two files
> > provided by the same package for different architectures are identical?
> Everything that can go wrong when splitting packages. You
Guillem Jover writes:
> On Wed, 2012-02-15 at 16:32:38 -0800, Russ Allbery wrote:
>> Guillem Jover writes:
>> > If packages have to be split anyway to cope with the other cases, then
>> > the number of new packages which might not be needed otherwise will be
>> > even smaller than the predicted
m...@linux.it (Marco d'Itri) writes:
> On Mar 01, Russ Allbery wrote:
>
>> The situation with refcounting seems much less fragile than the situation
>> without refcounting to me.
> I totally agree.
>
> Also, why does refcounting have to be "perfect"?
> What would break if it did not actually chec
m...@linux.it (Marco d'Itri) writes:
> On Mar 01, Russ Allbery wrote:
>> The situation with refcounting seems much less fragile than the situation
>> without refcounting to me.
> I totally agree.
> Also, why does refcounting have to be "perfect"?
> What would break if it did not actually check
On Mar 01, Russ Allbery wrote:
> The situation with refcounting seems much less fragile than the situation
> without refcounting to me.
I totally agree.
Also, why does refcounting have to be "perfect"?
What would break if it did not actually check that the two files
provided by the same package
Guillem Jover writes:
> About tightly-coupled files, they can cause serious issues also with
> refcounting, consider that there's always going to be a point when
> unpacking one of the new instances will have a completely different
> vesion than the other already unpacked instance(s). So packages
On Wed, 2012-02-15 at 16:32:38 -0800, Russ Allbery wrote:
> Guillem Jover writes:
> > If packages have to be split anyway to cope with the other cases, then
> > the number of new packages which might not be needed otherwise will be
> > even smaller than the predicted amount, at which point it make
Guillem Jover writes:
> On Thu, 2012-02-16 at 10:43:53 -0800, Russ Allbery wrote:
>> I was thinking more about this, and I was finally able to put a finger
>> on why I don't like package splitting as a solution.
>> We know from prior experience with splitting packages for large
>> arch-independe
On Thu, 2012-02-16 at 10:43:53 -0800, Russ Allbery wrote:
> I was thinking more about this, and I was finally able to put a finger on
> why I don't like package splitting as a solution.
>
> We know from prior experience with splitting packages for large
> arch-independent data that one of the more
Guillem Jover writes:
> On Wed, 2012-02-15 at 19:31:10 -0800, Russ Allbery wrote:
>> I think that the best long-term way to handle binNMUs may be to move
>> the build number into a different piece of package metadata from the
>> version. So a binNMU of a package with version 1.4-1 would still ha
On Wed, 2012-02-15 at 19:31:10 -0800, Russ Allbery wrote:
> I agree that it's asymmetric. apt-get install libfoo means libfoo:native,
> but apt-get remove libfoo means libfoo:*. And asymmetric is bad, all
> things being equal. But I think this may be one place where asymmetric is
> still the rig
On Wed, 2012-02-15 at 16:41:21 +, Ian Jackson wrote:
> Guillem Jover writes ("Re: Multiarch file overlap summary and proposal (was:
> Summary: dpkg shared / reference counted files and version match)"):
> > [...] But trying to workaround this by coming
> >
On Thu, 23 Feb 2012, Goswin von Brederlow wrote:
> > Package: 3depict
> > Source: 3depict (0.0.9-1)
> > Version: 0.0.9-1+b1
>
> Except that doesn't have to work (sorry for the ubuntu part):
>
> Package: gcc
> Source: gcc-defaults (1.93ubuntu1)
> Version: 4:4.4.3-1ubuntu1
>
> What would the versi
David Kalnischkies writes:
> On Thu, Feb 16, 2012 at 23:10, Carsten Hey wrote:
>> * David Kalnischkies [2012-02-16 03:59 +0100]:
>>> On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
>>> (the only problem i see is that i don't have ${source:Version} available
>>> currently in the version stru
Russ Allbery writes:
> I think it would be better to have a world in which all the architectures
> of the foo package on the system have to have the same version, because
> then you don't have to treat foo:i386 and foo:amd64 like they're separate
> packages. The list of installed architectures i
Joey Hess writes:
> Goswin von Brederlow wrote:
>> pkg:arch will still be unique and the dpkg/apt output will use the
>> architecture where required for uniqueness. So I think that after some
>> getting used to it it will be clear enough again.
>
> Here are a few examples of the problems I worry
Josselin Mouette writes:
> Le lundi 13 février 2012 à 22:43 -0800, Russ Allbery a écrit :
>> There's been a lot of discussion of this, but it seems to have been fairly
>> inconclusive. We need to decide what we're doing, if anything, for wheezy
>> fairly soon, so I think we need to try to dr
Russ Allbery writes:
> Carsten Hey writes:
>> * Russ Allbery [2012-02-16 14:55 -0800]:
>
>>> Every file that differs has to be fixed in the current multi-arch plan.
>>> Documentation that contains its build date is going to need to be split
>>> out into a separate -docs package.
>
>> I doubt tha
Russ Allbery writes:
> If this is comprehensive, then I propose the following path forward, which
> is a mix of the various solutions that have been discussed:
>
> * dpkg re-adds the refcounting implementation for multiarch, but along
> with a Policy requirement that packages that are multiarch
Jonathan Nieder writes:
> Jonathan Nieder wrote:
>> David Kalnischkies wrote:
>
>>> 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 &= ~al
On Fri, Feb 17, 2012 at 19:53, Carsten Hey wrote:
> * 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
* 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
* 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
Jonathan Nieder wrote:
> David Kalnischkies wrote:
>> 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
>> ?
[...]
> But I real
David Kalnischkies wrote:
> 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
> ?
>
> Isn't it more intuitive to have it this way:
On Fri, Feb 17, 2012 at 15:46, Jonathan Nieder wrote:
> David Kalnischkies wrote:
>
>> You generously left out the paragraph describing how APT should
>> detect that the package foo is in fact a library and not, say, a
>> plugin, a dev-package, a dbg-package or a future-coinstallable binary.
>> An
David Kalnischkies wrote:
> You generously left out the paragraph describing how APT should
> detect that the package foo is in fact a library and not, say, a
> plugin, a dev-package, a dbg-package or a future-coinstallable binary.
> And the foo:* default would be okay and intuitive for all of tho
On Thu, Feb 16, 2012 at 23:10, Carsten Hey wrote:
> * 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.
:all is already an archit
Carsten Hey writes:
> * Russ Allbery [2012-02-16 14:55 -0800]:
>> Every file that differs has to be fixed in the current multi-arch plan.
>> Documentation that contains its build date is going to need to be split
>> out into a separate -docs package.
> I doubt that ftpmaster would be happy about
* 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.
> Documentation that contains
Carsten Hey writes:
> * 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
* 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
* 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
I was thinking more about this, and I was finally able to put a finger on
why I don't like package splitting as a solution.
We know from prior experience with splitting packages for large
arch-independent data that one of the more common mistakes that we'll make
is to move the wrong files: to put
On Thu, Feb 16, 2012 at 09:26, Goswin von Brederlow wrote:
> Russ Allbery writes:
>> David Kalnischkies writes:
>>> On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
>>
Actually, why would that be the behavior? Why would dpkg --purge foo
not just remove foo for all architectures for
Russ Allbery writes:
> David Kalnischkies writes:
>> On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
>
>>> Actually, why would that be the behavior? Â Why would dpkg --purge foo
>>> not just remove foo for all architectures for which it's installed, and
>>> require that if you want to remove
Russ Allbery writes:
> David Kalnischkies writes:
>> Maybe it would help this kind of discussions if we would have a list of
>> interface changes in dpkg and how someone is supposed to use it in the
>> future in case this has changed - i personally lost track of that. (In
>> case someone wants
David Kalnischkies writes:
> On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
>> Actually, why would that be the behavior? Why would dpkg --purge foo
>> not just remove foo for all architectures for which it's installed, and
>> require that if you want to remove only a specific architecture y
On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
> Ian Jackson writes:
>> Joey Hess writes ("Re: Multiarch file overlap summary and proposal"):
>
>>> Here are a few examples of the problems I worry about. I have not
>>> verified any of them, and
Guillem Jover writes:
> If packages have to be split anyway to cope with the other cases, then
> the number of new packages which might not be needed otherwise will be
> even smaller than the predicted amount, at which point it makes even
> less sense to support refcnt'ing.
I don't think the pac
Ian Jackson writes:
> Joey Hess writes ("Re: Multiarch file overlap summary and proposal"):
>> Here are a few examples of the problems I worry about. I have not
>> verified any of them, and they're clearly biased toward code I am
>> familiar with, which s
1 - 100 of 369 matches
Mail list logo
