Bug 146552
Summary: | synaptic should set ExcludeArch: x86_64 cause BR apt also has ExcludeArch: x86_64 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Thorsten Leemhuis <fedora> |
Component: | synaptic | Assignee: | Panu Matilainen <pmatilai> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | scop, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-01-29 21:21:25 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Thorsten Leemhuis
2005-01-29 15:27:10 UTC
apt is not ExclusiveArch: i386 for good, it's just not quite ready for x86_64, or more precisely multiarch, I hear. Some people have expressed interest in fixing that in the future. Synaptic is not ExclusiveArch: anything AFAICT, so I see no reason to pollute it with such statements. BTW, maybe ExcludeArch: x86_64 (+ other multiarchs, if any) would be more accurate for apt, not ExclusiveArch. Panu? (/me thinks this bug should be closed as NOTABUG) Sorry Ville, yes of course you are right. Sorry. apt is "ExcludeArch: x86_64" (at least in my CVS copy); And hence synaptics should also. If apt is fixed for multilib this of course can be removed then. Well, I misremembered and it's good that apt is ExcludeArch already. But I think you missed my point: I don't see why synaptic should be polluted with stuff that it is not directly involved with it. apt not available for x86_64 is just a missing dependency which prevents us from shipping x86_64 synaptic for Extras, not something that should be hardcoded into the synaptic specfile, not even temporarily. For example, it would have been equally wrong to add libselinux-devel to all fedora.us FC2 KDE packages' BR's; the packages had nothing to do with SELinux whatsoever, but fam(-devel) had internal dependencies to it and missed the dependency -> anything using fam-devel even indirectly could not be built if libselinux-devel was not present. Better to leave those statements to places where they really are in instead of polluting other, "innocent" packages. Still NOTABUG as far as I'm concerned. >But I think you missed my point: I don't see why synaptic should be polluted >with stuff that it is not directly involved with it. apt not available for >x86_64 is just a missing dependency which prevents us from shipping x86_64 >synaptic for Extras, not something that should be hardcoded into the synaptic >specfile, not even temporarily. Good point; But I still think it should set ExcludeArch x86_64 as long as apt is not fixed so the build-system(s) knows that this package does not need to be built for x86_64. Otherwise it might create errorlogs that might get checked by people (and then they waste their time). >Still NOTABUG as far as I'm concerned. I still think its a bug. But only a small one. Panu? From my point feel free to close if you also think its NOTABUG. Well, you know my opinion. Let's let Panu decide what to do with this. Well, neither apt nor synaptic are exclusivearch anything techically, only the FC-style multilib usage isn't supported by either. The correct thing would be to exclude all multilib architectures from both synaptic and apt for now: ExcludeArch: x86_64 ia64 I dunno if PPC64 is multilib system, if so then that should be excluded as well. Isn't ia64 a 64-bit-only arch, ie. _not_ a multilib one? ia64 is 64-only. ppc64 is multilib. ExcludeArch: x86_64 ppc64 is best. I'm changing this now. Mm, right. Ia64 is not multilib in the sense that x86_64 is, it's even weirder piece of work with it's own weird issues from rpm management POV - you *can* install i386 rpm's on it, causing a "multilib" problems for apt. See the thread beginning at http://distro2.conectiva.com.br/pipermail/apt-rpm/2004- June/002390.html if interested... Hmm... s390/s390x might be multilib too. Maybe it is best that we ExclusiveArch: and explicitly list archs that we tested, and leave a comment there saying that? Such an ExclusiveArch statement would probably apply to the vast majority of packages we're shipping, given the rationale of "only tested on these archs"... hence I'd rather keep it like "we know it won't work on these archs", ie ExcludeArch. Not a big deal though. I tried to dig into rpm's code and see what it considers multiarch, but the code confuses me. In the "installplatform" file is this hunk: MULTILIBNO= case "${ARCH}-${OS}" in sparc-linux) MULTILIBNO=1 ;; sparcv9-linux) MULTILIBNO=1 ;; sparc64-linux) ARCH_INSTALL_POST=${pkglibdir}/brp-sparc64-linux; LIB=lib64; MULTILIBNO=2 ;; s390-linux) MULTILIBNO=1 ;; s390x-linux) LIB=lib64; MULTILIBNO=2 ;; ppc-linux) MULTILIBNO=1 ;; ppc64-linux) LIB=lib64; MULTILIBNO=2 ;; i?86-linux|pentium?-linux|athlon-linux) MULTILIBNO=1 ;; x86_64-linux|amd64-linux|ia32e-linux) LIB=lib64; MULTILIBNO=2 ;; esac if [ -n "$MULTILIBNO" ]; then MULTILIBSED='-e /^@MULTILIB/d -e s,@MULTILIBNO@,'$MULTILIBNO, else MULTILIBSED='-e /^@MULTILIBSTART@/,/^@MULTILIBEND@/d' fi MULTILIBSED is used to mangle the macros file. So perhaps that implies that the ones with MULTILIBNO=2 are "multilib" archs as in this context, and ones with MULTILIBNO=1 possibly can participate as a "secondary arch" in these multilib scenarios? That hunk does not list ia64 at all, BTW. rpmrc's arch_compat statements contain further info which archs are "compatible" with each other. "So perhaps that implies that the ones with MULTILIBNO=2 are "multilib" archs as in this context, and ones with MULTILIBNO=1 possibly can participate as a "secondary arch" in these multilib scenarios?" makes sense to me. IA64 is a truly wicked beast. Rpm does an explicit test for incompatible arch (i386 is not listed as compatible there) on ia64 and then goes to perform funky path relocation to /emul/i386/ root. The package shows up in rpmdb normally AFAIK causing the usual multilib-problems with apt however... Anyway, based on the above it'd look like "ExcludeArch: x86_64 ppc64 s90x sparc64" would be the way to go, and I personally think adding ia64 there as well would be a good idea since apt will probably want to do something nasty if you install i386 packages on it. |