Re: Cross-upgrading packages with multiarch packages
Hi, On Sat, 19 Feb 2011, Steve Langasek wrote: > > If this needs 2 dpkg calls, one for removing, one for reinstalling then > > I'm flat out against it. That would harm all the reverse depends and > > cause significant blockage on upgrades. > > No, that's what 'dpkg --remove --force-depends' is for, which I believe is > exactly how apt already handles conflicts on upgrade. That's how apt handles the case, indeed. But it's something that we'd like to get rid of at some point. dpkg already has code to ignore conflicts from a package that is marked as being removed so it would be nice if frontends could use this facility instead. (But that's orthogonal to this discussion, I just wanted to point it out) Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110220075946.gf11...@rivendell.home.ouaza.com
[PATCH] lib/dpkg: removed duplicated #include
Signed-off-by: Andrea Gelmini --- lib/dpkg/path.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/lib/dpkg/path.c b/lib/dpkg/path.c index b2c958b..cdb77b3 100644 --- a/lib/dpkg/path.c +++ b/lib/dpkg/path.c @@ -22,7 +22,6 @@ #include #include -#include #include #include #include -- 1.7.4.1.129.g8adf4 -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1298237324-7057-1-git-send-email-andrea.gelm...@gelma.net
Re: Bug#594179: dpkg armhf patch acceptance status?
+++ Guillem Jover [2011-02-18 11:13 +0100]: Guillem makes some good points about how GNU triplets should (and once did) represent ABIs, and that if they still did, dpkg (and everything else) could use them as the definitive ABI-indicator. He's quite right. _Something_ has to stand as nomenclature for the ABI. It could equally well be GNU triplets or Multiarch Tuples. I'm quite happy for either to be used. Multiarch directories could use triplets under those circumstances and there would be no need for the new tuples. But it is also the case that a given toolchain can produce binaries of different ABIs, so there is logic in the GCC argument that the triplet denotes a toolchain, not (necessarily) an ABI. (e.g arm-linux-gnueabi toolchain can produce armel and armhf binaries (and in fact there are more incompatible ABIs it could spit out, but we're not trying to make distros out of those). It makes sense to me that, these days, a triplet represents a toolchain, and an MAtuple an ABI. If there was a 1-1 mapping between these things then triplets would suffice, but there isn't. So it seems to me, that we either have to persuade GCC to go back to one triplet per ABI or we need to adopt the proposed Tuples. It is logically neater in many ways to go back to one-triplet-per-ABI, but like Steve, I'm not optimistic about this being ultimately acceptable to upstream or that it could be done in a sensible period of time. Starting again with a properly defined list and some rules about new identifiers lets us get it right this time, and arrange for it to stay right in the future. So what happens if we do this? Let's look at some examples mentioned so far: > * I think it's important to be able to consistently support co-installing > different default cross-compilers for different ABIs which would > otherwise share the same triplet. And while we could avoid the problem > for multiarch libraries co-installations by using the multiarch tuples, > we would not be able to avoid it for the cross-compilers. This is true, but in fact the arm-linux-gnueabi and arm-linux-gnuhf toolchains would be the same apart from their libgcc and default options (spec file). A multilib build of this toolchain, supporting both options, would work for targetting both ports, but we do still lack a good way of switching spec files to change the default target (which would be useful for all sorts of reasons). > * The assumption that each GNU triplet denotes a different ABI is so > entrenched in the GNU build system, that we have things like the > following all over the place to properly support cross-building: > > ,--- > ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE)) > confflags += --build $(DEB_HOST_GNU_TYPE) > else > confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) > endif > `--- > > This would not hold true any longer if we didn't use a unique triplet > per arch, and would thus break in quite annoying ways. Yes, this is potentially a pain in the bum. We need to select a toolchain (which could be 'arm-linux-gnueabi' for both arm port targets, but with different default options and a different default linker and include paths). I haven't yet worked out how those will be selected, as currently they are built-in to the cross-compiler and referring to it by name sets them implicictly. debian/rules has access to the -a which allows the necessary discrimiation, and automatically supplies the /etc/dpkg-cross/cross-config. autoconf values, which may be sufficient, along with config.guess. There are a lot of instances of -L /usr//lib which need fixing for multiarch anyway, so even if we have unique GNU triplets, work will be needed in lots of packages to make cross-building work again. Anything which already relies on default compiler paths should work fine. If using non-unique toolchain triplets, we need a robust mechanism for host ABI selection within the multilibs available. > * Ignoring the bi-directional 1:1 mapping would be a PITA, as it implies > not being able to automatically bootstrap dpkg on a new port or > dpkg package builds on foreign distros. The former is annoying but not > done frequently, the latter is going to be a problem for each non-dpkg > based distribution, as they'll have to bootstrap dpkg on each arch > where dpkg is built anew. It ends up being a matter of off-loading the > knowledge of the arch and build system from the dpkg/gcc combo to the > porters/maintainers, which seems rather unappealing. I don't think I understand this point. Who are these people that build dpkg on non-dpkg distro, and why will they have harder bootstraping? > > > The toolchain has the same triplet for binary incompatible producing > > > objects, which seems like a bug/misfeature to me, and that's one of > > > the assumptions dpkg-dev has relied on, in the same way as multiarch > > > when deciding to use the triplet as a unique token for the installation > >
Re: Bug#594179: dpkg armhf patch acceptance status?
+++ Steve Langasek [2011-02-18 17:36 -0800]: > > * The remaining problem at least for multiarch is the use of more > > specialized cpu names for the i386 triplets, i486-linux-gnu on Debian, > > which might change depending on the base instruction set to support, > > for example i686-linux-gnu on Ubuntu. > > > Due to #611741, it already crossed my mind (but removed it from the > > list of solutions before sending the reply as at the time it seemed > > slighly preposterous just to fix the divergence with Ubuntu) that we > > should switch back our i386 arch to use i386 as the base cpu name for > > the triplet (i386-linux-gnu) in the same way we use it in other > > arches, like on arm where we use arm-linux-gnu instead of something > > like armv4tel-linux-gnueabi, for example. (I mentioned this already to > > Steve and Raphaël on some private conversation.) > > The challenge, as Matthias points out, is that these triplets are already so > entrenched and there is so much software that handles x86 specially - even > if incorrectly! - that it's prohibitive to switch back to i386-linux-gnu as > our triplet because of all the re-porting work we'll have to do to get > properly functioning packages on x86. I know little of x86 world, but are we sure this is more work than the fixing-up we'll need to do in many packages to properly deal with multiple available ABIs within a toolchain, and making the new MAtuples be used correctly everywhere? (especially when cross-building, for both matters). > The underlying intent of the tuples proposal is that we stop pretending that > GNU triplets provide a valid global one-to-one mapping to ABIs, because we > know from several concrete, high profile examples that this is not true. > > You have proposed a patch that Matthias has said "looks ok", but if he adds > it to the Debian/Ubuntu gcc, that only solves the problem for Debian and > Ubuntu. Multiarch is intended as a cross-vendor standard, fixing the FHS's > inadequate lib directories and providing binary interoperability for > anyone choosing to implement it. How can we achieve that if we're using > strings in our paths that are dependent on distro-specific patches? Do we > expect to tell other implementors they have to use our GCC? > > The multiarch tuple proposal would externalize this problem by establishing > a central, standard, one-to-one mapping between ABIs and strings *for this > precise purpose*. I agree that this establishment of a generic FHS multiarch library path standard is the right thing (TM), and that it's no good if it can't be done upstream . But equally Guillem is right that ABI-sepecific triplets could do that job too (and with less change to existing practice overall). > Given that there is no consensus that this is even a bug to be fixed, I am > not content to have multiarch blocked indefinitely on getting triplet fixes > propagated upstream; nor am I happy to have multiarch paths tied to > distro-specific implementation details. Are you going to do the heavy > lifting to get these changes accepted by GCC upstream? How long do you > think that will take, and at what point would you decide that you're not > getting anywhere and fall back to diverging from upstream for multiarch? This is the nub of the practical problem. > I've rather firmly committed to getting initial multiarch support landed in > the 11.04 Ubuntu release. If we can (collectively) get our decision made on > the path selection *now*, that's achievable - and we can be rid of ia32-libs > from Debian (unstable) and Ubuntu within a year, and we can bring armhf up > as the first multiarch-from-the-start port in Debian. If we instead let > ourselves get drawn into open-ended discussions trying to persuade GCC > upstream that we're right about triplets and they're wrong, it may be years > longer before we see any multiarch implementation at all. Remember that we > were discussing multiarch before sarge was released - I don't want to still > be discussing it after wheezy is out. :( I guess I missed the first 3-odd years of this debate. I'm assuming we've already tried reasonably hard persuading the GCC people on this point? Unless the feature of being able to separately specify toolchains (triplets) and ABIs (tuples) is important (and it may be for biarch/triarch arches, but I'm not yet convinced), then given the extreme similarity of tuples and triplets, it does seem like ABI-specific triplets would be a 'better' solution to this problem than inventing a new set; and in general Debian likes to go for the technically-best solutions even if it takes longer. (Multiarch in general is an example of this). However, equally, it's taken a really long time to get this far, and if we made a reasonable effort to get GCC people to agree with guilem's view of the world, but failed, then I'm happy that the expediency of the new tuples is justified. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloo
Re: [PATCH] lib/dpkg: removed duplicated #include
Hi! On Sun, 2011-02-20 at 22:28:44 +0100, Andrea Gelmini wrote: > Signed-off-by: Andrea Gelmini > --- > lib/dpkg/path.c |1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/lib/dpkg/path.c b/lib/dpkg/path.c > index b2c958b..cdb77b3 100644 > --- a/lib/dpkg/path.c > +++ b/lib/dpkg/path.c > @@ -22,7 +22,6 @@ > #include > #include > > -#include > #include > #include > #include Thanks for the patch, I've queued it for my next push. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110221042020.ga12...@gaara.hadrons.org
Re: Bug#594179: dpkg armhf patch acceptance status?
[ Sorry for entangling the armhf bug with the i386 stuff, subsequent
replies should probably remove debian-arm and the bug report from
them. ]
On Fri, 2011-02-18 at 13:30:19 +0100, Matthias Klose wrote:
> On 18.02.2011 11:13, Guillem Jover wrote:
> >[ CCing Matthias, as I'd like your opinion on my proposed solution
> > involving some Debian gcc changes. ]
>
> The armhf patch for gcc looks ok, however I would like to see this
> better addressed in Linaro and/or upstream.
Ok, I'll run it through upstream to see what they say. I just wanted
to check if you'd be fine including it regardless of upstream's stance
on it, to at least be able to decide on the armhf triplet issue, the
multiarch paths decision would be unrelated to this then.
> >> Yes but x86 goes to the other extreme, with separate triplets for
> >> compatible ABIs ({i386,i486,i586,i686}-linux-gnu); the fact is the
> >> triplet is not a good ABI specifier.
> >
> >Sure, but as mentioned above, I'm now convinced the correct solution is
> >to switch back to i386-linux-gnu.
>
> No, this doesn't work. the triplet currently is set to
> i586-linux-gnu. Switching back to to i386 would loose the sync
> primitives and a not working gomp. There is too much relying on >=
> i586 in many configure's of other packages.
Oh, I think this actually strengthens my point!
The gcc-4.4:i386 package seems to be compiled on Debian to target i586
as the base instruction set, as can be seen in its debian/rules2:388,
which implies changing the triplet would not affect this (barring the
small change I'm attaching a patch for, untested), and thus the sync
primitive and gomp would be fine (at least from my understanding of
the gcc build system). And just to make this perfectly clear, I'm
not proposing to downgrade the actual instruction set base line.
So while the base instruction set was changed to i586 in gcc 4.4.0-1~exp1
it did not switch the GNU triplet to i586-linux-gnu to match:
$ dpkg --print-architecture
i386
$ gcc-4.4 -dumpmachine
i486-linux-gnu
$ gcc-4.5 -dumpmachine
i486-linux-gnu
$ gcc-4.6 -dumpmachine
i486-linux-gnu
$ grep ^i386 /usr/share/dpkg/cputable|tr -s '\t '|cut -f2
i486
So I don't see how any debian/rules could be currently relying on
the i586-linux-gnu triplet (as long as they set them correctly through
the dpkg-architecture variables, coming from gcc, and not from
config.guess).
Also having to transition all our packaging to the new triplet every
time i386 changes the base line does not seem right, and it's
something we don't do on any of the other architectures. I'd even say
it's just wrong, packages should either use the default compiler base
instruction set, set their required one independenly of it, do
multiple builds and use hwcaps for libraries or do run time detection.
Given the above we'd need to either switch to i586-linux-gnu or
i386-linux-gnu, it seems to me both will imply the same amount of
changes? And thus going for the latter seems the correct solution,
it matches with the other architectures, can be used as the multiarch
paths and can reduce some divergence with Ubuntu, all of them a clear
win! :)
> Not only for the good, as the switch in Ubuntu to i686 did show,
> because many configure files assume sse with i686-linux-gnu.
I'd say any such assumption in those packages is buggy, per above.
thanks,
guillem
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110221063219.ga22...@gaara.hadrons.org
Re: Bug#594179: dpkg armhf patch acceptance status?
On Mon, Feb 21, 2011 at 02:22:44AM +, Wookey wrote: > > The challenge, as Matthias points out, is that these triplets are already so > > entrenched and there is so much software that handles x86 specially - even > > if incorrectly! - that it's prohibitive to switch back to i386-linux-gnu as > > our triplet because of all the re-porting work we'll have to do to get > > properly functioning packages on x86. > I know little of x86 world, but are we sure this is more work than the > fixing-up we'll need to do in many packages to properly deal with > multiple available ABIs within a toolchain, and making the new > MAtuples be used correctly everywhere? (especially when > cross-building, for both matters). "multiple available ABIs within a toolchain" is not a problem that has to be solved on x86 today, so yes, it is more work. On x86 we do have at least one tuple identifier for each ABI - we just have the problem that we have /too many/ of them available on x86. But while multilib toolchains are definitely of interest on x86 (-m32/-m64), each of these ABIs also have a distinct tuple associated with them (x86_64-linux-gnu, i86-linux-gnu). > > You have proposed a patch that Matthias has said "looks ok", but if he adds > > it to the Debian/Ubuntu gcc, that only solves the problem for Debian and > > Ubuntu. Multiarch is intended as a cross-vendor standard, fixing the FHS's > > inadequate lib directories and providing binary interoperability for > > anyone choosing to implement it. How can we achieve that if we're using > > strings in our paths that are dependent on distro-specific patches? Do we > > expect to tell other implementors they have to use our GCC? > > The multiarch tuple proposal would externalize this problem by establishing > > a central, standard, one-to-one mapping between ABIs and strings *for this > > precise purpose*. > I agree that this establishment of a generic FHS multiarch library > path standard is the right thing (TM), and that it's no good if it > can't be done upstream . But equally Guillem is right that > ABI-sepecific triplets could do that job too (and with less change to > existing practice overall). Multiarch is a significant departure from existing practice one way or the other. I think the question of whether we maintain our ABI string list as a delta against GNU triplets or as an entirely separate standard is really quite a minor detail in comparison. > I guess I missed the first 3-odd years of this debate. I'm assuming we've > already tried reasonably hard persuading the GCC people on this point? In the x86 case, it's not something that GCC people can fix. The overloading of GNU triplets on x86_32 is now a well-entrenched practice throughout the community, and neither they nor we can fix by fiat the consequences of changing our triplet - only by a lot of hard work. In the armhf case there was an upstream mailing list discussion, from which the only emerging consensus (to the extent we can say there was one) was that the official GNU triplet should stay the same. This mailing list discussion informed the BoFs we had at DebConf about multiarch tuples, and I think it qualifies as "tried reasonably hard". It's hard enough for my purposes, because I'm not out to try to dictate policy to the GCC maintainers, so when they say that's not what triplets mean, I greatly prefer finding a path of lesser resistance. I thought we had that with the multiarch tuples proposal, but maybe not. :/ > Unless the feature of being able to separately specify toolchains > (triplets) and ABIs (tuples) is important (and it may be for > biarch/triarch arches, but I'm not yet convinced), then given the > extreme similarity of tuples and triplets, it does seem like > ABI-specific triplets would be a 'better' solution to this problem > than inventing a new set; and in general Debian likes to go for the > technically-best solutions even if it takes longer. (Multiarch in > general is an example of this). I don't see either of these to be technically better or worse. The fact is that we are going to *have* to document multiple points where our directory strings do not follow naturally from the existing array of GNU triplets; and that documentation needs to be maintained in a readily consumable fashion. Given those constraints, I don't think that using a modified set of GNU triplets is any better than creating new strings from scratch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
x86 triplets and multiarch [Was, Re: Bug#594179: dpkg armhf patch acceptance status?]
On Mon, Feb 21, 2011 at 07:32:19AM +0100, Guillem Jover wrote: > Given the above we'd need to either switch to i586-linux-gnu or > i386-linux-gnu, it seems to me both will imply the same amount of > changes? And thus going for the latter seems the correct solution, > it matches with the other architectures, can be used as the multiarch > paths and can reduce some divergence with Ubuntu, all of them a clear > win! :) Why i586 for the multiarch path? That's an arbitrary baseline, based on what Debian is currently targeting. How do I sell that to the LSB and to other distributions, most of which AIUI now use i686 as their least common denominator? It's not even what Ubuntu is targeting, so you haven't actually reduced any divergence there: $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 10.10 Release:10.10 Codename: maverick $ dpkg-architecture -ai386 -qDEB_HOST_GNU_TYPE 2>/dev/null i686-linux-gnu $ > > Not only for the good, as the switch in Ubuntu to i686 did show, > > because many configure files assume sse with i686-linux-gnu. > I'd say any such assumption in those packages is buggy, per above. Yep, software is buggy. We should be careful not to design a system that fails because it requires software to not be buggy. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
