yum repos shouldn't just be attributes to channels. Instead, they should be objects themselves so that several channels can be associated to the same yum repo, which would only get synced once, then. As an example: There's only one Adobe (AdobeReader, flash-plugin) repo (per architecture) for all Linux-distributions. So if I have F10/11, RHEL 3-5, CentOS 3-5 and maybe more I would have to sync that repo for all of them instead of only once. I know, the packages are only saved in the system once anyway, but that doesn't stop the sync to download them a multitude of times.
* when that repo is synced as a part of one channel, it is not resynced automatically in other channel - This was not intended to be done. * when the repo is synced as a part of one channel and then synced again as a part of another channel, all packages are downloaded again - TODO Added code in commit 734a36aea070062f11530cc6ba0e7f9900218245 to do this, however it only works if the checksum in the repo matches the checksum that we generate for a package. The newer fedora repos do this. For example, with most older repos, the packages are checksumed as sha1, but we only store the md5sum of the package. So we can't know for sure if a package has already been downloaded until we download it again. Since it was decided during the sha256 work to only store a single checksum of a package, there's no way to work around the issue. We could look for a package within the same org that has the same NVREA, but this will break the ability for spacewalk users to sync RHEL and CentOS (or RHEL and Fedora) content. It would be possible to only do this check if enable_nvrea is disabled (in which case it wouldn't even work if nvrea is disabled). Going to move this to modified, unless someone has something more to suggest :}
> * when the repo is synced as a part of one channel and then synced again as a > part of another channel, all packages are downloaded again - TODO > > Added code in commit 734a36aea070062f11530cc6ba0e7f9900218245 to do this, > however it only works if the checksum in the repo matches the checksum that we > generate for a package. The newer fedora repos do this. > > For example, with most older repos, the packages are checksumed as sha1, but we > only store the md5sum of the package. So we can't know for sure if a package > has already been downloaded until we download it again. Since it was decided > during the sha256 work to only store a single checksum of a package, there's no > way to work around the issue. > > We could look for a package within the same org that has the same NVREA, but > this will break the ability for spacewalk users to sync RHEL and CentOS (or > RHEL and Fedora) content. It would be possible to only do this check if > enable_nvrea is disabled (in which case it wouldn't even work if nvrea is > disabled). > > > Going to move this to modified, unless someone has something more to suggest :} You are right, I have been watching /var/log/httpd/access_log, so although sync of second channel containing same repo as a previously synced channel lists the package, I see it is not downloading it - PASS
As per comment #7 and comment #3, marking this as VERIFIED.
I confirm following behavior: * one repo can be associated with multiple channels * when a repository will be synced within a channel, it has to be synced within another channel2 to get the repo packages into the channel2 * when syncing repository within a channel (package download), package download has to proceed when syncing the same repository within another channel as well (as stated in Comment#6) Note: when syncing x86_64 repo into a i386 channel, incompatibility will be correctly recognized: "Package arch x86_64 incompatible with channel google-chrome-i386" STAGE VALIDATED on Satellite-5.4.0-RHEL5-re20101015.0
The 5.4.0 RHN Satellite and RHN Proxy release has occurred. This issue has been resolved with this release. RHEA-2010:0801 - RHN Satellite Server 5.4.0 Upgrade https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10332 RHEA-2010:0803 - RHN Tools enhancement update https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10333 RHEA-2010:0802 - RHN Proxy Server 5.4.0 bug fix update https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10334 RHEA-2010:0800 - RHN Satellite Server 5.4.0 https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10335 Docs are available: http://docs.redhat.com/docs/en-US/Red_Hat_Network_Satellite/index.html Regards, Clifford