Bug 591534

Right, I've done some work upstream to do this:

In PackageKit:

commit f28b67440608ae5eb7c19ad382e1c71c9bec269f
Author: Richard Hughes <richard>
Date:   Wed May 12 15:01:39 2010 +0100

    yum: Attempt to use removable disk repos if they exist at backend startup

:100644 100644 1faa5aa... 579f3e7... M  backends/yum/pk-backend-yum.c
:100755 100755 2c5f54c... f90ce59... M  backends/yum/yumBackend.py

commit f8ffbcee30252b1dff776e5663bbc88174060e0f
Author: Richard Hughes <richard>
Date:   Wed May 12 12:10:21 2010 +0100

    yum: Remove all the MediaManager implementations and write a small GIO based callback

:100644 100644 a0af1a4... 0c96ef1... M  backends/yum/Makefile.am
:100755 100755 13afbd8... 2c5f54c... M  backends/yum/yumBackend.py
:100644 000000 735edc1... 0000000... D  backends/yum/yumMediaManager.py
:100644 000000 690c84b... 0000000... D  backends/yum/yumMediaManagerDeviceKit.py
:100644 000000 e71e8f3... 0000000... D  backends/yum/yumMediaManagerGIO.py
:100644 000000 a249e1d... 0000000... D  backends/yum/yumMediaManagerHAL.py
:100644 000000 0a5a4c5... 0000000... D  backends/yum/yumMediaManagerOS.py

commit d6464be3475f3b505a0f62ba44994ace9034e0da
Author: Richard Hughes <richard>
Date:   Wed May 12 12:04:50 2010 +0100

    Use the new PkTask API in pkcon so we can deal with Media and Eula queries

:100644 100644 34e4132... e8dc4dc... M  client/pk-console.c

commit b9bbcf001b6adcb6faf43f2ce1ca115aa541fe53
Author: Richard Hughes <richard>
Date:   Wed May 12 12:03:51 2010 +0100

    glib: add sync versions of the new API in PkTask

:100644 100644 8da09d2... a6b9b9c... M  lib/packagekit-glib2/pk-task-sync.c
:100644 100644 e192e2a... 666f83b... M  lib/packagekit-glib2/pk-task-sync.h

commit 31217d5862df8aed1708cbc14b80eb57550de16e
Author: Richard Hughes <richard>
Date:   Wed May 12 12:03:24 2010 +0100

    glib: Add some new PkTask methods that handle the Media and Eula callbacks for the application

:100644 100644 fd0709e... c2fa44d... M  lib/packagekit-glib2/pk-task.c
:100644 100644 f128941... 16f36df... M  lib/packagekit-glib2/pk-task.h

commit 0244fe8f011425fc36d74c69f17e339665e82c31
Author: Richard Hughes <richard>
Date:   Wed May 12 12:00:07 2010 +0100

    Show the MediaChangeRequired signals in pkmon

and in gnome-packagekit:

commit b8e737ff64a8b7395e2b2dfd916cd07043495ea8
Author: Richard Hughes <richard>
Date:   Wed May 12 09:47:00 2010 +0100

    Watch when removable discs are inserted and call GetUpdates() if it is detected as repo media

:100644 100644 51e86e5... 502a9ce... M  data/gnome-packagekit.schemas.in
:100644 100644 d6a454c... edecfe1... M  src/gpk-check-update.c
:100644 100644 8d9300d... 8b7a39c... M  src/gpk-common.h

You can test this by using a up to data f13 and rebuilding the PackageKit and gnome-packagekit packages available here: http://people.freedesktop.org/~hughsient/fedora/

Doing it properly (no locks, or random errors, etc) turned out to be quite a bit of code, but I guess we could bodge something smaller for a possible backport.

Applied to PackageKit in RHEL-6:

* Wed Jun 09 2010 Richard Hughes  <rhughes> - 0.5.8-7
- Backport a patch from upstream that adds support for support media repos
  such as those found on additional CDs.
- This patch only adds the auto-add part, and the command line tools will not
  prompt for the disk if it is not installed.
- This functionality also relies on the media being auto-mounted, but this is
  thankfully the default on a RHEL6 install.
- Resolves: #591534

Applied to gnome-packagekit in RHEL-6:

- Backport a patch from upstream that adds support for support media repos
  such as those found on additional CDs or DVDs.
- This patch just calls GetUpdates after a detected media repo is inserted,
  which is enough for PackageKit to add the repo to the default set, and for
  the repo to be used in all the GNOME and KDE tools.
- This patch will not add explicit support for media repos in client programs,
  so the media is not requested if it is not inserted when the package tools
  are open. This functionality can be backported at a later time if required.
- Resolves: #591534

The builds are here (you need both for the complete fix):
 - http://brewweb.devel.redhat.com/brew/taskinfo?taskID=2505813
 - http://brewweb.devel.redhat.com/brew/taskinfo?taskID=2505840

Now, if you insert an additional CD, then:
* It is mounted by the session, just like normal
* gnome-packagekit recognizes it's a media disk and pokes PK out of its slumber
* PackageKit copies the repo file from the disk to /etc/yum.repos.d/
* All the client code (pkcon, GNOME and KDE tools) now treat the media repo just like any other repo, and you get a warning if the repo can't be reached
* If you remove the CDROM and then try to search for a package on the media repo, it won't be found (as the repo is disabled if the metadata is not contactable)
* If there's no CDROM and you explicitly install a package you know is on the disk, then you get a message saying the repo is disabled. This isn't ideal, but it's a fair bit more work to connect up all the MediaRequestRequired dialogs in all the right places in the gnome-2-28 era code.

Or, put simply, I think this is probably a sweet spot between back-porting a ton of new code and making things work for RHEL 6.0.

(In reply to comment #2)
> Now, if you insert an additional CD, then:
> * It is mounted by the session, just like normal
> * gnome-packagekit recognizes it's a media disk and pokes PK out of its slumber
> * PackageKit copies the repo file from the disk to /etc/yum.repos.d/

This all sounds very good.  

A few questions:
Does PackageKit look specifically for a file name media.repo, or does it look for anything matching *.repo?
What's the name of the file that gets placed under /etc/yum.repos.d?
Does the section (the part between []) or name in the repo matter or need to be unique?

(In reply to comment #3)
> Does PackageKit look specifically for a file name media.repo, or does it look
> for anything matching *.repo?

It identifies the disc as interesting if media.repo or .discinfo. exists. The former needs to exist to be used as a system repo. I think media.repo is the only repo filename that is on additional media, but correct me if I'm wrong.

> What's the name of the file that gets placed under /etc/yum.repos.d?

packagekit-media.repo

> Does the section (the part between []) or name in the repo matter or need to be
> unique?    

I'm pretty sure we can only support one media repo inserted at any time -- the identifier in the media.repo seems to always be "InstallMedia" and two repos with the same ID would confuse yum.

That said, we could use the repo id as the suffix for the repo file if you want, as that allows people to use more than one media repo at the same time if they are sure the id's are different. I'm not so keen on this as we can add packagekit-media.repo as a %ghost if we have to, but I don't think we can do that with a wildcard.

Richard.

Hello Richard,

I think that the behavior have to be changed. See following scenario:
 

1) User inserts suitable CD/DVD  into a drive (in my case RHEL6 installation media)
2) Waiting for 30s
3) PackageKit creates a record in /etc/yum.repos.d
4) User ejects and removes CD/DVD from the drive
5) User makes yum related action: (Behavior should be different)

bash-4.1$ sudo yum search python
Loaded plugins: refresh-packagekit
Error: Cannot retrieve repository metadata (repomd.xml) for repository: InstallMedia. Please verify its path and try again


6)  user ejects media

7) user performs yum-related action (I think that in case that metadata can't be retrieved && repo_file.url == packagekit-media.repo -> packagekit-media.repo should be removed/disabled)

bash-4.1$ yum search firefox
Loaded plugins: refresh-packagekit
Error: Cannot retrieve repository metadata (repomd.xml) for repository: InstallMedia. Please verify its path and try again

8) packagekit-media.repo needs to be removed or disabled manually


Please give me your opinion about this

(In reply to comment #6)
> bash-4.1$ sudo yum search python
> Loaded plugins: refresh-packagekit
> Error: Cannot retrieve repository metadata (repomd.xml) for repository:
> InstallMedia. Please verify its path and try again
> Please give me your opinion about this    

Right, the problem is that yum appears to abort if any repo is not available, even media repos. Whilst I disagree with this logic (and have argued with Seth about it for a few hours now :-) we probably need to just do the right thing and disable the MediaRepo repo when PackageKit has finished.

I've checked this into git this morning:

commit 7dd3421197de0bc8444069984436239f28d78862
Author: Richard Hughes <richard>
Date:   Fri Jul 2 11:43:22 2010 +0100

    yum: Ensure we disable the MediaRepo when the PackageKit backend has finished
    
    YUM is unable to ignore repos that do not exist, even media repos
    and this stops yum working if the media is not present.
    
    PackageKit is a bit more clever and can ignore (with a warning)
    sources that do not exist or are not contactable but we still need
    to preserve compatibility for people who use both the PackageKit
    tools and the yum CLI.
    
    Ensure we set the enabled= line in the repo file so that any tool
    that cannot skip repos is able to continue working.

:100644 100644 b56316b... 6e6844f... M  backends/yum/pk-backend-yum.c

I've asked people affected by it to test my Fedora build. I've updated the brain dump here: http://people.redhat.com/rhughes/media-repo.txt with the additional logic, which I would kindly ask you to sanity check.

Thanks.

Hello Richard,

Works as expected so I'm moving this to verified. I found one issue with gpk-application, but this should be filled as a separate bug.

VERIFIED on:

PackageKit-0.5.8-8.el6

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

Note that this seems to have regressed since about February 2011, when gpk-update-icon was killed and the functionality moved to gnome-settings-daemon. See https://bugzilla.redhat.com/show_bug.cgi?id=888307 .