91 lines
5.0 KiB
Plaintext
91 lines
5.0 KiB
Plaintext
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 Apper 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.
|
|
|