Bugzilla – Bug 156593
Package Manager is missing importing and exporting of package lists
Last modified: 2007-02-16 10:43:32 UTC
The YaST Software Management lost the ability to import/export package list. People who exported their package list prior to a new installation instead of doing an upgrade might be surprised that they cannot import their list after installation anymore.
We should not drop that feature.
still missing in beta 8
*** Bug 159723 has been marked as a duplicate of this bug. ***
*** Bug 159678 has been marked as a duplicate of this bug. ***
This is a UI function. Stefan, please re-enable this after syncing with Stano. cc to visnov. The main problem is probably that we have to generate two fileformats, one .sel (for sl10.1) and one .pat (for sles/sled). But as there are only very minor differences between these files, this should be rather straightforward.
There is no support in libzypp for that AFAIK.
After second beta period enhancement and one week without comments, the status of this bug entry(with two duplicates) is still on 'NEW'. Is anybody working on the implementation of the lost functions or will we get an "WONTFIX'?
This will be not done for 10.1.
As this is very usefull feature, is there an alternative ? It seems that autoinstall do something similar, but I found it very complex, just to save a package list, and the docs are not helping, as it says that you need a file.sel for custom selection. But it doesn't tell you how to create one, and doesn't explain the .sel file format, probably presuming the export/import menu option. I'm really high and dry for repeated installations.
*** Bug 177904 has been marked as a duplicate of this bug. ***
Just go another bug report by e-mail. Let's make sure to reintroduce this with one of the next openSUSE alphas. Stano, Michael, do you want an official feature request (Fate) for 10.2, or is this Bugzilla sufficient?
> Stano, Michael, do you want an official feature request (Fate) for 10.2, > or is this Bugzilla sufficient? Does this mean it won't even be done for SLES/SLED? If your machines are very different, autoinstall does not make sense, but importing a predefined selection does.
Just a note: SLES/SLED does not use selections anymore, but patterns.
Can someone answer if there is a workaround for the problem? Commandline or otherwise.
Ping
What the status about comments #6,#8 and #12? Was the feature completely deleted or is anybody working to find a solution for upcoming Opensuse 10.2?
Still missing in OpenSuse 10.2 beta 1 What should we expect for the final 10.2?
(In reply to comment #21) > Still missing in OpenSuse 10.2 beta 1 > What should we expect for the final 10.2? The installation workflow of openSUSE 10.2 is officially feature-frozen since 4 weeks already. Please change the "Product" field of this bug to openSUSE 10.3 once it is available.
Unfortunately, this will not make it into 10.2. Please, use the command line tools to workaround this problem. We are aware that this is an regression.
It has come up again on IRC. Michael, ping? Possible workaround: Export: $ rpm -qa --queryformat '%{NAME}\n' | LC_ALL=C sort > package_list Import: # yast2 -i ./package_list or # rug in `cat package_list` or # zypper in `cat package_list`
(In reply to comment #24) > # rug in `cat package_list` AFAIK this will choke on already installed packages.
Basically the UI would be able to do this the same way the ycp code does on installation, when it saves the transaction and restores it after boot. But Huha is right, zypp does not yet support this by providing some standard format to save the lists. The UI would be free, and in need, to use it's own format.
Implemented (as a new feature - this cannot possibly be CRITICAL, it was a missing feature, nothing else) with FATE feature #300729 with yast2-qt-2-13.75. It does what that feature request specifies: Export patterns and packages and import them, disregarding all hardware dependencies etc. Users will still be much better off doing the proper thing: Cloning their system with AutoYaST and using that cloned profile to set the new system up properly with AutoYaST. AutoYaST has that kind of intelligence (and fault tolerance) that a simple package import/export lacks.
I had been watching this bug off an on. In checking again, I am very surprised (shocked would be better) to see it labeled as Resolved. But maybe I misunderstand something. I don't see what the solution actually is for me. I have yast2-qt-2.14.3-5 on my system. But there are no Import/Export options in Software Manager (the original bug description). I have no idea what FATE #300729 is, or how to make use of it. A couple of points. This issue cannot possibly be an Enhancement. It was put out to restore a feature that had been with SuSE for a very long time, but which was (#$%*&^@) removed by someone. Not having it has been an extreme, very time-consuming pain. I would indeed call it Critical (to productivity and health)! AutoYaST will not do the job. It applies, as best as I can tell, to a full installation of systems that are essentially all clones. But I have computers of different architectures: single processors or SMP; single or dual boot; different disk sizes and partition structures; wireless or wired; fixed IP or DHCP;... But what they do have are similar (but not identical) sets of software rpms. I keep an ascii list of the installed rpms on each computer. When I upgrade and install a new version of SuSE, I once was able to use the file in Software Manager, after installation, to add/delete rpms (both) -- reviewing any proposed changes. If I had to reinstall the system for some reason, I was back up to where I was in no time. I could use a list from one computer to be the base for a new computer, again reviewing the selections for necessary changes. Instead, now, it literally takes me hours (!) per computer to carefully compare my list with the rpms available in Software Manager, and make adjustments. If there is now something that does these tasks for me, I would like to know and have it made available. A simple import/export package does things that a complex AutoYaST can't. And users can actually understand it. To add/delete rpms, I use a mouse to put check marks or trash cans in little boxes. I can not understand how it is so difficult to have Software Manager read a very simple ascii file and do exactly the same thing. Computers are supposed to be good for that sort of thing.
The fix is available in FACTORY (our development tree) and will be part of openSUSE 10.3. That's why the bug is resolved as fixed. We consider this to be an enhacement to the new ZYPP-based stack, so we do not plan to backport the functionality to already released box distributions.
(In reply to comment #30) > I have yast2-qt-2.14.3-5 on my system. ...which came with openSUSE 10.2. yast2-qt-2-13.75, the version mentioned above, will be on SLE-10 SP1. That is the same code base as openSUSE 10.1 (a.k.a. as SUSE Code-10). As far as openSUSE is concerned, this feature is released with yast2-qt-2.14.4 (openSUSE factory, which will eventually become openSUSE 10.3). > This issue cannot possibly be an Enhancement. I beg to differ. It is. > AutoYaST will not do the job. It applies, as best as I can tell, to a full > installation of systems that are essentially all clones. Not quite. > But I have computers of different architectures: single processors or SMP; > single or dual boot; different disk sizes and partition structures; wireless > or wired; fixed IP or DHCP;... AutoYaST is a lot better dealing with all this, in particular with different kinds of hardware. You can even set up rules for partitioning for different size disks. And you can also leave some things open for manual intervention. AutoYaST is a very powerful tool. If you have that kind of heterogeous environment, please do yourself the favour and give AutoYaST a try. You will very likely find it makes a lot of tedious and error-prone manual work a lot easier. > ... > ...to use the file in > Software Manager, after installation, to add/delete rpms (both) -- reviewing > any proposed changes. Review them you will have to, and very carefully, too -- because of all the things that AutoYaST has some built-in intelligence, whereas that export/import feature is a very dumb literal export and import. It does not care about what kernel you should install. It installs the same the original machine had. It does not care about hardware-dependent other packages. You will get the exact same as on the original machine. It does not know anything about architectures. For multi-architecture systems like x86_64 you may or may not get what you want. You have to look very carefully. Again, this is something that AutoYaST is a lot better at. > If I had to reinstall the system for some reason, I was > back up to where I was in no time. That's about the only really useful use case that comes to my mind. > I could use a list from one computer to be the base for a new computer, That OTOH is a very dangerous thing to do. Because... > again reviewing the selections for necessary changes. ...this reviewing will be solely your responsibility. > To add/delete rpms, I use a mouse to put check marks or trash cans in little > boxes. I can not understand how it is so difficult to have Software Manager > read a very simple ascii file and do exactly the same thing. Computers are > supposed to be good for that sort of thing. Well, basically that's what it does - and with no more intelligence, too. But that's simply not enought for many, many use cases -- see above. Bottom line: You really might want to give AutoYaST a try. I think you will like it. OOo presentation about installation and AutoYaST: (skip the first 100 or so slides to get to AutoYaST) http://www.suse.de/~sh/brainshare/sles-installation-and-autoinstallation.sxi AutoYaST info: http://www.suse.de/~ug/
I've been a little busy and distracted. Your reply is very helpful. Thank you for the installation file. I agree with you about the dangers of the simple approach, and I take the responsibility and am careful about them. (Of course, having my fingers slip and typing 'rm *' instead of 'rm *.<something>' is much more dangerous, but I don't like to set the option to confirm each file.) I'll give a closer look at autoyast. In the meantime, if I replace yast-qt with yast-qt-2.14 (or later) from FACTORY, will I get the capability I want, or will other things break - maybe even badly? From the developer viewpoint the issue may be an enhancement. But from my user point of view, it is a restoration of a lost feature. This doesn't matter as long as the capability is there.
(In reply to comment #33) > In the meantime, if I replace yast-qt with yast-qt-2.14 (or later) from > FACTORY, will I get the capability I want, or will other things break - > maybe even badly? You'd have to update at least all the packages yast2-qt depends on to FACTORY, including libzypp. This in turn will drag in a host of other dependencies. You'd end up with most (but probably not all) of FACTORY. If you are willing to take that risk (it's an alpha release, after all), I recommend you simply install the latest snapshot, i.e. some 10.3-Alpha. As with all alpha versions, this entails a certain risk; if you have business-critical applications running on that machine, I would advise against it.