Media Repo Support in PackageKit Tools

Reference: rh#591534

Pirut was the system level updating tool which PackageKit aims to replace in
RHEL 6. Pirut had functionality where users could insert additional media to
install add-on software not present in official repositories, on rhn, or on the
install media. This disc was locked by the yum process and could not be removed
while the application was running. Pirut used the yum MediaGrabber functionality
which in turn used HAL to mount, unmount and lock the disk.

In a post-HAL, user-interface driven GIO based world a lot of the concepts to
provide this functionality are broken. For instance, gvfs is automatically
mounting the media in the user session, and the media cannot be locked for
exclusive use by any one subsystem or program. CDs and DVDs are gradually being
replaced with USB key drives, and these can be removed at any time.

During the PackageKit 0.4.x development cycle, code was added to PackageKit,
gnome-packagekit, and kpackagekit projects to support the use case of software
sources on external media. This was not wired up in PackageKit 0.5.x, but the
UI's client have translations for this feature. Late in the 0.6.x series this
functionality was backported into 0.5.x and therefore the feature will be
present for the initial release of RHEL 6.0 and Fedora 13.

The core functionality of the feature can be split into three logical blocks:

1. Mounting and notification by the session process. In GNOME the process
   gpk-update-icon watches for media being mounted and unmounted either by the
   user or automatically. This feature also relies on the media being
   auto-mounted, but this is thankfully the default on a desktop install.
   When the GIO monitor notifies gpk-update-icon that media has been inserted
   g-u-i checks the mountpoint contains a media.repo file in the root directory.
   This media.repo has to be a standard MediaRepo file recognised by yum to
   work usefully. If the media is correct, the session component asks the daemon
   to get the new update list, which is sufficient for the daemon to be started
   and for phase 2 to be started.

2. The daemon starts, and the compiled backend initialization is run. This looks
   for mounted volumes, and copies any media.repo files from the removable media
   to /etc/yum.repos.d/packagekit-media.repo, overwriting any existing file.
   The packagekit-media.repo is appended with an "enabled=1" line to ensure
   it is used by the yum CLI.
   The users request is then processed, which will typically be the GetUpdates()
   call from the g-u-i session process, but could be any user request.

3. The python yum backend starts, and the list of software sources is loaded.
   Any media sources that are not mounted are disabled, but not deleted.
   yumBackend.py then installs a MediaGrabber callback into yum, so that if
   packages on the media source are required then the correct mountpoint is
   passed back to yum. The MediaGrabber code uses the .discinfo file on the root
   of the media to confirm if the disk is the correct disk for the metadata.
   .discinfo is created for additional media disks and the main DVD install
   media at generation time.

4. When the PackageKit transaction is finished, the packagekit-media.repo file
   is set with "enabled=0". This ensures that tools such as yum that cannot
   handle missing or uncontactable repos do no abort at startup. As yum cannot
   prompt for media to be inserted, this is a sensible precaution.
   The user will have to manually (as root) change the "enabled" line to "1"
   using an editor is they want to use removable media repos with the command
   line yum tool.

If the daemon is already running the compiled PackageKit backend will have
already been loaded. This maintains a GIO watch on mounted volumes, and will
automatically copy the repository file whilst current transactions are running.
Yum, however, will only recognize the new media repo when the next transaction
is scheduled. This is probably an acceptable compromise.

All the client code (pkcon, GNOME and KDE tools) now treat the media repo
just like any other repo, and the user gets a warning if the repo can't be
reached. If the user removes the CDROM and then try to search for a package on
the media repo, it will not be found.
If there's no CDROM and the user explicitly install a package you know is on the
disk, then you get a message saying the repo is disabled. This isn't ideal, and
can be addressed for 6.1 by connecting up the required UI elements.

Functional Test:

* Log in to a graphical shell such as GNOME
* Insert addition media disk into the computer
* Observe the media is mounted by the session
* Wait a couple of seconds
* Observe the /etc/yum.repos.d/packagekit-media.repo now exists
* Do "pkcon search name java" and observe the additional java packages available
* Open gpk-application and observe the addition category in the groups treeview
* Remove media disk
* Do "pkcon search name java" and observe the standard java packages only

Any questions, concerns or corrections to rhughes@redhat.com please.