> YAST should have the option to choose between having auto close and
> closing at the users leisure.
this is really good idea, dear developers please take a look on this. In
many situations it is very annoying.
I think we need some yast discussion features.
Personnaly I have update in my system and something goes wrong. So i’ll be
very appritiated to devellopers if I have any button to rool back to last
(or some custom date) state of my packages.
One more thing I’ll be glad to see in yast it is desktop update. something
in one click updating all packages from one repo to another.
for example i hsave kde4.3.1 from repo
opensuse 11.2
some time past appears repository kde432
so i want only point my new repository and have all related packages updated
from their.
> This issue has been solved long time ago…Start Yast - System -
> sysconfig editor, search for “action” and you will be able to change
> ‘pkgmgr_action_on_exit’. The option ‘summary’ gives the opportunity to
> review changes made and …return to package manager. Using that for
> over a year now.
I did not know about that thanks.
I presume BTRFS will be able to do something similar.
In the meantime, you could play with NixOS, which uses functional package management - although it’s experimental, and I don’t think you would use it as a main OS.
Nonetheless, such ideas are certainly in the long-term pipeline…
I mean something different. I mean yast should save list of rpms and repos.
and in one click it should be recovered to some preset list. (maybe this
will be clearer?)
> I presume BTRFS will be able to do something similar.
ZFS and BTRFS maybe really great but, as for desktop… I am absolutely
satisfied with ext3
I’m not technically minded enough to assess whether that’s possible, but I guess there would be problems insofar as packages aren’t just discrete blobs, they have configuration files, directory structures, bits of themselves they leave dotted around the place. Getting them to uninstall cleanly seems hard enough, and getting them to successfully revert back to an old state must be harder.
With snapshots you can achieve the same thing, reverting back to some point in time - you can ignore the messy details, but have to sacrifice more disk space.
I guess the question as to which way works better resolves to the balance of how much disk space snapshots take up, versus how much effort would have to be put into scripting things to ‘surgically’ revert individual packages.
But functional package management does let you do more or less what you’re talking about. Trouble is, it eats disk space too…
Hi
That was the one good thing about rug it has a rolback feature (when
enabled) could rollback if updates screwed the system. It’s one feature
that needs to be written into zypper.
