From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040929 Description of problem: I have developed a small patch to up2date which I would like product management to consider for inclusion in an official up2date errata. The patch enables 3 new command-line options which are useful to all users of up2date. These options are useful in enabling a single machine to be able to pull down RHN updates for multiple RHEL releases across multiple platforms. Version-Release number of selected component (if applicable): up2date-4.4.5.6-2 How reproducible: Always Steps to Reproduce: New command-line options: 1) --downloadall: This option enables the retrieveOnly flag, but sets pkgList to the entire list of packages available in a channel. It requires the --channel option as well. 2) --systemid: This option overrides the location of the systemid file which is used when connecting to RHN. I can have 4 systemid files (systemid-as4-i386, systemid-as4-x86_64, systemid-as3-i386, systemid-as3-x86_64) and switch between them at will on a single machine. Of course, on my RHEL 4 machine, I have to use the --upgrade-to-release 3AS flag in order to connect to the RHEL 3 channels, but as long as my systemid files are legitimate, this works like a charm. 3) --quiet: This option currently affects the up2dataBatch.py run method. Typically, wrapperUtils.printVerboseList is always called which prints the entire channel contents (when used with --downloadall). This new option disables the printVerboseList. It also disables printing the # marks when each package is downloaded in getPackages. Examples (all run on RHEL 4 i386 host): 1) Download all RHEL 4 i386 updates up2date --channel rhel-i386-as-4 --downloadall --systemid /var/tmp/systemid-as4-i386 --tmpdir /auto/linux/sandbox/brilong/up2date-download/rhel-i386-as-4 --force --quiet 2) Download all RHEL 4 x86_64 updates up2date --channel rhel-x86_64-as-4 --downloadall --systemid /var/tmp/systemid-as4-x86_64 --tmpdir /auto/linux/sandbox/brilong/up2date-download/rhel-x86_64-as-4 --force --quiet --arch x86_64-redhat-linux 3) Download all RHEL 3 i386 updates up2date --channel rhel-i386-as-3 --downloadall --systemid /var/tmp/systemid-as3-i386 --tmpdir /auto/linux/sandbox/brilong/up2date-download/rhel-i386-as-3 --upgrade-to-release 3AS --force --quiet 4) Download all RHEL 3 x86_64 updates up2date --channel rhel-x86_64-as-3 --downloadall --systemid /var/tmp/systemid-as3-x86_64 --tmpdir /auto/linux/sandbox/brilong/up2date-download2/rhel-x86_64-as-3 --upgrade-to-release 3AS --quiet --arch x86_64-redhat-linux Additional info:
*** Bug 162211 has been marked as a duplicate of this bug. ***
Created attachment 116187 [details] up2date Patch
Created attachment 117835 [details] SRPM with integrated patch
It turns out I had a bug in my original patch and SRPM. My patched up2date would download all packages from all channels even when --channel was specified. I'm attaching a new patch and SRPM which fixes this problem.
Created attachment 119630 [details] Fixed up2date Patch
Created attachment 119631 [details] Fixed SRPM with integrated patch
Created attachment 119843 [details] Patch for up2date from RHEL 4 U2 (4.4.50-4).
Created attachment 119844 [details] SRPM for up2date-4.4.50-4 (RHEL 4 U2) with patch applied
Tried this and its great having problems with RHWS 4 and x86_64 arch downloads. I can download all i386 packages but no x86_64 packages with the --downloadall option and the systemid for an appropriate machine. If I use the --showall it shows me the x86_64 packages.
Make sure you follow the instructions in the original bug description to the letter. For example, if you run this on RHEL 3 but you're downloading RHEL 4, you have to use --upgrade-to-release=4AS. This also works in reverse. If you're running on RHEL 3, but need to download 2.1, --upgrade-to-release=2.1AS. Also, for x86_64, make sure you specify --arch x86_64-redhat-linux.
Thanks Brian. I was hoping that it was me not reading it properly but still no joy. If it helps here is a snip of what I get when 1/ I download the rpms and 2/ I show the rpms. The system I'm running from is a RHAS4 i386 box trying to get the downloads for a RHWS4 x86_64 box. 1/ /usr/mlocal/bin/up2date --nox --channel rhel-x86_64-ws-4 --showall --systemid /usr/mlocal/etc/systemids/systemid-smerla-RHWS4-x86_64 --upgrade-to-release=4WS --arch x86_64-redhat-linux --tmpdir /redhat/updates/4WS/x86_64 --force 4Suite-1.0-3.x86_64 Canna-3.7p3-7.EL4.x86_64 Canna-devel-3.7p3-7.EL4.x86_64 ..... 2/ /usr/mlocal/bin/up2date --nox --channel rhel-x86_64-ws-4 --downloadall --systemid /usr/mlocal/etc/systemids/systemid-smerla-RHWS4-x86_64 --upgrade-to-release=4WS --arch x86_64-redhat-linux --tmpdir /redhat/updates/4WS/x86_64 --force Storage directory: /repo/redhat/updates/4WS/x86_64 Fetching all package list for channel: rhel-x86_64-ws-4... ######################################## Canna-libs-3.7p3-7.EL4.i386.rpm... ######################################## FreeWnn-libs-1.10pl020-5.i386.rpm... ######################################## .... showall shows the x86_64 rpms I need. downloadall only gets the i386 rpms but appears to be on the right channel.
If I run downloadall with all appropraite flags and system ids I can download all the x86_64 packages for a different RH version with a different systemid. i.e. everything works fine. If I run the same command with the same flags and system id on a i386 box it only downloads the i386 rpms.
just so your sure I do have the --arch='x86_64-redhat-linux' specified both times
This modified up2date works really well, but one minor problem I'm having is that it doesn't seem to fetch the i386 packages from the x86_64 repo. There are some 227 i386 packages in the x86_64 repo but they don't seem to show up when I run up2date like this: /usr/bin/up2date --channel rhel-x86_64-as-4 --downloadall --tmpdir /var/www/html/yum/4AS/updates/x86_64 --quiet Am I doing something wrong or is this a bug?
I'd like also the '--showall' switch to SEE all packages available for the specified channel.
Product Management has reviewed and declined this request. You may appeal this decision by reopening this request.