As part of GSoC 2008, Shishir Goel added Service Pack functionality to PackageKit. To explain what a service pack is, it’s best to show a few use-cases.
- You have seven desktops you’ve just installed with Fedora 9. Each one needs to have 204Mb of updates installed.
- You have a laptop that needs network drivers before it can download updates, and you have a similar up to date laptop with internet access nearby. The network drivers require a ton of dependencies, and other packages to be upgraded before they will install.
- You frequently install Linux on other peoples computers. You carry around a live-cd and a pendrive with a single 204Mb file “Fedora-updates-SP1.servicepack” which contains all the updates since last week.
Now, you may or may not know, that you have been able to install .servicepack files since PackageKit 0.3.2 — but creating them has always been tricky. Yesterday I spent a few hours rewriting some of the client code, and making the pkgenpack command line options more sane.
The pkgenpack is a command line tool for creating service pack files. You can find out more information about how it works by reading the man page.
Yes, I know the man page formatting sucks, suggestions on how to fix (and patches!) welcome.
Internally, the pack file is just an uncompressed tarball, with the packages and a single metadata.conf file inside. The metadata file is just the distro_id (name, version, arch, etc) and the time of creation. This ensures you don’t try installing a fedora-9-i386 service pack on a ubuntu-intrepid-ppc machine. In this case you also get a nice error message telling you what you did wrong.
Now, command line tools are all the rage these days, but what about a GUI? I mocked this up in glade yesterday, and wouldn’t take too long to turn into an actual program.
Comments?
Sounds interesting. One summer I had to craft an offline by-proxy apt setup to carry packages from work to my offline Debian box at home. This would solve that problem more effectively. It’s ‘dependencies’ btw :)
Usually, I think this dialog should disappear once you hit ‘Create’, and be replaced with a new dialog that indicates progress. In your mock, setting the preferences and watching progress is in the same dialog, which is a bit strange.
That is awesome! I could have used something like that quite often!
Keep up the good work!
Looking at the three use cases you outlined above, I think the suggested GUI doesn’t go far enough. The GUI is better than command line fiddling, but it could be even much more better than that :-)
For the first use case, a central “package cache” seems more sensible to me, assuming all seven desktops are on a network. At least for Ubuntu + APT there have been ideas floating around of ad-hoc created caches, announced with Avahi, without needing manual configuration. This would allow to update all desktops automatically without downloading every package seven times over internet.
If the desktops are not on a network, it still seems fragile to me to create an SP of “all pending updates” – it assumes that the other systems have exactly the same updates installed as the current one. Something like “all updates that appeared over the last week” seems more sensible to me. This could also cover the third use case (by creating a SP with “all updates that appeared since F9 was released”).
The “hal-info” text field should probably be a listbox or something like that, listing all available packages (don’t make the user enter the package name as string). Focusing on the second use case, the list could also offer some “abstract” targets, like “make a SP with all network drivers and network-manager-packages and related stuff you can find” (so the user doesn’t have to dig around on the target machine to find out which driver and stuff is required).
Then, what is the “Exclude list file”? If it’s a list of packages to exclude from the SP, why not let the user enter those package names right in the GUI?
Next, as little gimmick, the “hughsie” destination selector could maybe also prominently offer any connected USB sticks? That might help to reduce the number of clicks required by the “average” user to create an “average” SP.
Finally, does this tool require that the current system has all these packages installed locally, or does it download them directly from the net? Bonus points if the tool even works distro-independent – would be nice to use an Ubuntu system to create a SP for Fedora, or the other way round :-D
Maybe just me, but I feel it’s a case of creeping featuritis. I can’t think of a situation where I’d ever really need it.
1) a proxy would be adequate for that.
2) I’ve never had a network driver with dependencies?
3) if you go to the trouble of making a SP, you might as wel have burned a new up-to-date Live CD (a CDRW works well for live CDs).
Don’t get me wrong – I can see how this feature adds some flexibility. I just think you shouldn’t forget your focus.
@oliver:
“The “hal-info” text field should probably be a listbox or something like that, listing all available packages (don’t make the user enter the package name as string).”
A listbox probably wouldn’t be the best choice. Imagine listed 10000+ packages listed in a listbox. Would you be happy with that?
Some kind of search functionality would be the best to select packages, like the one Synaptic has.
@nano
One more use case:
A free software magazine wants to distribute patent encumbered multimedia plugins and programs with the latest Fedora release DVD. They want a way in which even the most lazy user can get the things installed without much fuss.
Burning a new LiveCD is might not be as trivial as lumping the updates into a service pack. It it was trivial then the Fedora Unity folks would have stopped earning brownie points for the Fedora re-spins they make. :-)
Moreover, if you think of a home user in a country where Internet connectivity is quite costly (eg., India), then the network related problems start to make more sense. eg., one really can not expect a home user to set up a caching proxy, which will not help if there is a single computer at home.
I think the date would be pretty essential for SP creation, as you’re really creating an image of updates available up to the current date. The next morning your distro may release more updates and your SP will already be out of date. Maybe you should make the date visible in the GUI? Having the number of updates and total file size would help as well.
what is needed is to not have to download 10MB of updates because a single file in OOo changed or something.
What’d be nice is to have the server create a minimal package on the fly, and send just the “diff” to you. Then you only need the one 2kb file and some minimal header information to make sure you know you’re at the right version. Or perhaps, using the diff and existing files, yo
this frickin trackpad tap-to-click crap is driving me nuts. My thumb hits the trackpad when typing, but Ubuntu doesn’t have an elantech driver so it’s detected as a scrolly-mouse and I can’t turn off the fricking tap-to-clikc behavior
“Or perhaps, using the diff and exiting files, yo”u could re-assemble the full package from the cached previous version or even from the files on your disk (you already have them; why re-download them?) This seems to be the best way to do this immedately; “diff-packages” would require intervention in rpm and dpkg.
@Botond: right, a listbox wouldn’t be that helpful either. A search box might be better; or maybe make it similar to the existing app-installer GUI elements?
@Debarshi: the use case of updating a machine that’s connected with low bandwidth or an expensive connection would be interesting to me as well. I had to support one such machine myself and ended up with some scripts around apt and dpkg which did the downloading etc. (it was quite a PITA). It would be nice if these uses cases were officially supported by the distros, but unfortunately these problems are often met with “let’s just wait until the user gets a better connection -> problem solved”.
@Joseph: AFAIK Debian now uses some mechanism to publish package list diffs at least (see http://www.debian-administration.org/articles/439). Not sure if this has been extended to actual packages as well, though.
@Joseph: Highly requested. I even downloaded the full texlive packages (latex) twice now, and looking in the changelog it seems only the build system was changed or similar. That means.. 2 times > 400 MB for something that has 0 effect !! Of course I chose to update the packages myself but why think, I just lazily do “aptitude safe-upgrade”..
@oliver: there are no package diffs, only the package list diffs in debian. I don’t know if there is any WIP.
“Service pack” is a silly name, and that Microsoft Windows uses it does not stop it from being a silly name. It has nothing to do with service. Alternative possibilities include “update pack” or “combined update”.
“Generator” is possibly too introspective. If people will be launching this program via the overall package manager, rather than standalone, it would make more sense to use a task-based title, such as “Prepare a Combo Update”.
In your mockup, the phrase “Create an archive of” is used twice in quick succession, which means the labels need refactoring.
“Details” is not a useful heading, and could easily be removed.
“Close” should be “Cancel”.
this could be great for doing installs inplaces that dont have network access (or only have dialup).
what it would need is to be able to putting in all the packages relative to a standard install. so from a currently up to date F9 install, i could make a service pack that would bring a fresh F9 install up to date. (and the same for making an installer). From the description above it looks like i could only make such a service pack with a fresh F9 install.
thanks
I’m with @ssam here, I have a bunch of networkless fedora machines where it would be easier to apply updates/upgrades if we could provide the /var/log/rpmpkgs log or equivalent to a simple UI like this and generate the update pack for a different machine.
BTW, a UI where you could hit a ‘Generate update pack request’ button that gathers all the info needed from a target machine and puts it in some PK file format, so you can ask users to push it+send you the file periodically so you can generate and give them an update CD or DVD would be awesome :)
Angel: I’ve added an option in the GUI. Refresh the screenshot. :-)
There’s also a large entry in the help file explaining what all these options mean. It’ll be in Fedora rawhide on Monday.
Great work! I would hope that distributions would pick something like this up pretty soon so that you can create servicepacks from e.g. ubunut.org
without the need to even run linux.
I wrote down my idea in more detail here.
http://brainstorm.ubuntu.com/idea/12998/
But I guess developing something like this should be picked up by the distros
themselves.
Thanks, Fabian
Is this tool similar to APTonCD ??