[softwaremgmt] Need to log packages installed by off-line one-click install (fate #305582)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Federico Lucifredi wrote:
Feature #305582, revision 19 Title: Off-Line one click install (MSI for Linux)
#12: Benjamin Weber <benji@opensuse.org> (2008-12-18 19:21:11) (reply to #11) Getting a bit off topic but some of the reasons it's not trivial to implement the uninstall is that you a) need the history of what packages were installed as part of the installation (including automatically selected dependencies)
I'm not sure why. Do you suggest that we should be able to list packages (or the whole bundles) installed via the off-line one-click inst? I would say there is no need for that - packages from the bundle will get installed, the bundle repository will get removed, but the packages will still be known to the package management just like they would if you installed any packages from any repo and then removed that repo. What is the problem with that?
b) Need to only remove the packages that were installed by the original installation but are not required by anything else that was installed subsequently (we don't want to uninstall unrelated things).
Here again, you will use the package management to remove any software you don't want anymore just like you do now. Why invent something more on top of that? Well, there is one thing that comes handy - the removal of unused packages (the packages installed by solver and not required by any other package) - but this will be implemented anyway. Here i suggest two modes for this: 1) cleaning up the whole system from unused packages 2) removing only those packages that are becoming unused based on the user's request in a transaction. The information about who installed a package (solver or user/application) we alread have. What else do we need? This way, you can install FOO dragging in any packages from the bundle and later uninstall FOO anytime, removing also any unused stuff it would leave.
c) Need to cope with users removing individual packages manually since installation. When do we decide that the application is no longer installed?
Again. Why complicate this? Any reason not to stick with current concept of installed status of an application, i.e. per-package?
The biggest problem is a) As we do not have a transaction- level history of what packages were stored afaik,
We don't (we only log who installed what, but not in which transaction). But why do we need this?
and are certainly not tieing it to application level metadata.
I'm not sure what do you mean by this.
#14: Duncan Mac-Vicar <dmacvicar@novell.com> (2008-12-18 20:52:19) (reply to #13) Yes. Benjamin is right. We are looking into this concept. There is a thread in zypp-devel about this, and it is more complex than it sounds (requires the algorithm to know where the package comes from and why it was installed, information that is right now not available).
Which thread is that?
+ #16: Federico Lucifredi <flucifredi@novell.com> (2008-12-20 08:02:36) + the idea is interesting, but if it is really self-contained like an + MSI. With repos involved, I am not so sure... (referring to ml + discussion)
The suggestion is to pack the repo _into_ the bundle, so the whole thing would be self-contained. No external repos (well, except the mandatory prerequisite of some base system - the distro DVD, or stable online repo, but i guess this can't be really solved (even the MSI isn't completely self-contained, or is it?), we just need to find the best compromise). - -- cheers, jano Ján Kupec YaST team - ---------------------------------------------------------(PGP)--- Key ID: 637EE901 Fingerprint: 93B9 C79B 2D20 51C3 800B E09B 8048 46A6 637E E901 - ---------------------------------------------------------(IRC)--- Server: irc.freenode.net Nick: jniq Channels: #zypp #yast #suse #susecz - ---------------------------------------------------------(EOF)--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAklPXkQACgkQgEhGpmN+6QEbhQCfSDEMp7rSFbVTGjruzW0j9heM +s4An2iVnSdBmmJiABy3wqf4Wj0RwdTo =heXg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
2008/12/22 Jan Kupec <jkupec@suse.cz>:
#12: Benjamin Weber <benji@opensuse.org> (2008-12-18 19:21:11) a) need the history of what packages were installed as part of the installation (including automatically selected dependencies)
I'm not sure why. Do you suggest that we should be able to list packages (or the whole bundles) installed via the off-line one-click inst? I would say there is no need for that - packages from the bundle will get installed, the bundle repository will get removed, but the packages will still be known to the package management just like they would if you installed any packages from any repo and then removed that repo. What is the problem with that?
This sounds like it could be an acceptable simplification for the offline version, where you would have essentially one repository per application. However, there could still be complications if the offline OCI could specify an online repository for updates; If the offline OCI pulls in dependencies from other online repositories during installation the user might want to remove those at the same time. The online version could be pulling packages from several different repositories. I would like a solution that works regardless of how the software was installed. So for users installing a set of packages either via zypper or sw_single or offline/online OCI. Could we have some way of logging what software was installed as part of a particular transaction. Then these transactions could be displayed to the user to select one to remove. This could remove any user-selected and automatically-selected packages that are not required by any packages outside this transaction.
b) Need to only remove the packages that were installed by the original installation but are not required by anything else that was installed subsequently (we don't want to uninstall unrelated things).
Here again, you will use the package management to remove any software you don't want anymore just like you do now. Why invent something more on top of that?
Because users don't want to have to remember the list of packages that gets installed by OCI or otherwise to go and remove them manually later.
Well, there is one thing that comes handy - the removal of unused packages (the packages installed by solver and not required by any other package) - but this will be implemented anyway. Here i suggest two modes for this:
1) cleaning up the whole system from unused packages 2) removing only those packages that are becoming unused based on the user's request in a transaction.
The information about who installed a package (solver or user/application) we alread have. What else do we need?
This way, you can install FOO dragging in any packages from the bundle and later uninstall FOO anytime, removing also any unused stuff it would leave.
The bit I believe is missing is if the user or an automated process installs FOO and BAR which drag in some dependencies and the user later wants to remove FOO and BAR together, because to the user they're part of the same installation.
c) Need to cope with users removing individual packages manually since installation. When do we decide that the application is no longer installed?
Again. Why complicate this? Any reason not to stick with current concept of installed status of an application, i.e. per-package?
Because people are saying they don't remember which packages were installed together. Which is understandable.
We don't (we only log who installed what, but not in which transaction). But why do we need this?
See above
and are certainly not tieing it to application level metadata.
I'm not sure what do you mean by this.
If there was the possibility for the application doing the installation to add to the log that this installation was for "Multimedia Support" or "KDE4" then these could be later displayed to the user for removal and more meaningful than "packages foo bar and baz on date $date" I'm not yet sure that storing transaction history is the best way towards providing the easier uninstall functionality that users want, but at the moment I can't think of a better system that would work across different tools. -- Benjamin Weber -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
participants (2)
-
Benji Weber -
Jan Kupec