Bug 438343 - Multilib issues with package syncs between two x86_64 systems
Multilib issues with package syncs between two x86_64 systems
Status: CLOSED DUPLICATE of bug 428139
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Other (Show other bugs)
510
All Linux
high Severity high
: ---
: ---
Assigned To: Brad Buckingham
Steve Salevan
: Triaged
Depends On:
Blocks: 456985 471789
  Show dependency treegraph
 
Reported: 2008-03-20 09:57 EDT by Máirín Duffy
Modified: 2009-08-07 12:00 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-12 13:31:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Máirín Duffy 2008-03-20 09:57:33 EDT
Description of problem:

<stahnma> in satellite 4.2.1 if you sync packages between two x86_64 systems,
using the profiles options, it does not sync i386 packages that are installed
(such as 32 bit glibc-devel).
Comment 4 Brad Buckingham 2009-02-12 13:31:55 EST
As part of bug 428139 extensive modifications were made to the system profile capabilities of the Satellite with respect to supporting packages with different architectures.

Modifications included:
- during creation of a profile, store package arch
- during profile comparison, include arch in the comparison and resulting "differences" displayed to the user
- during profile syncing, allow user to sync packages based on the arch differences noticed during the profile comparison

For example, if a system had libjpeg.i386 and the system was compared to a profile that had only libjpeg.x86_64, this difference would be shown during the comparison.  Then if the user chose to do so, they could select removal of the libjpeg.i386 from the system or installation of the libjpeg.x86_64 on the system as part of the 'sync to system' capability.

Since the solution for this BZ was implemented by another (428139), will mark this one as a 'duplicate'.

*** This bug has been marked as a duplicate of bug 428139 ***

Note You need to log in before you can comment on or make changes to this bug.