19 responses to “Service Pack GUI?”

  1. Jon

    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 :)

  2. Michaël

    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.

  3. Tom

    That is awesome! I could have used something like that quite often!

    Keep up the good work!

  4. oliver

    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

  5. nona

    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.

  6. Botond Szasz

    @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.

  7. Debarshi Ray

    @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.

  8. SindrePB

    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.

  9. Joseph

    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

  10. Joseph

    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.

  11. oliver

    @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.

  12. ulrik

    @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.

  13. mpt

    “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”.

  14. ssam

    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

  15. Fedora Service Pack « Juanfgs’s Blog

    […] en el blog de Richard Hughes que se esta trabajando en la GUI de un generador de Service Pack para Fedora, si bien la palabra […]

  16. Angel Marin

    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 :)

  17. Fabian

    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

  18. Marcelo

    Is this tool similar to APTonCD ??

Bad Behavior has blocked 2769 access attempts in the last 7 days.