I’m upgrading from 12.3 to 13.1. I’m also upgrading my hard drive so I can’t do an online upgrade. I had previously exported a list of all the installed (12.3) packages from Yast2 - Software Management. I did a “standard” install of 13.1 to the new hard drive, no additional packages, and then tried to import my installed package list from 12.3 into 13.1 to get back to my previous environment - only 13.1 marked all the packages for deletion. How can I get all the packages I previously had installed in 12.3 installed into 13.1 without having to add them one by one?
As you do not explain how you made that list, nor anything of how it looks like, I can only speculate. But probably the version indications are part of the package names. And for 13.1 there will most probably be newer versions for most packages. Thus editing the file with the list of packages, removing the versions and then doing zypper in on every of them might be a solution.
But it will not help e.g. when packages changed names, where merged, or otherwise reorganised between the two openSUSE versions.
On 2014-04-24 17:46, hcvv wrote:
>
> As you do not explain how you made that list, nor anything of how it
> looks like, I can only speculate.
Yes, he did say it 
>> I had previously exported a list of all the
>> installed (12.3) packages from Yast2 - Software Management.
In 13.1, yast sw-single QT flavour, it is in the “File” menu, and it is
called “export”. The default file name is “user-packages.xml”, and it
is, of course, an XML file.
Mine has this appeareance:
> <?xml version="1.0" encoding="UTF-8"?>
> <syscontent>
> <ident>
> <name></name>
> <version epoch="0"/>
> <description></description>
> <created>1398370745</created>
> </ident>
> <onsys>
> <entry kind="package" name="zypper-log" epoch="0" ver="1.9.12" rel="16.1" arch="noarch"/>
> <entry kind="package" name="yast2-nfs-server" epoch="0" ver="3.0.0" rel="2.1.4" arch="noarch"/>
> <entry kind="package" name="yast2-nfs-common" epoch="0" ver="3.0.0" rel="2.1.4" arch="noarch"/>
> <entry kind="package" name="yast2-nfs-client" epoch="0" ver="3.0.2" rel="1.3" arch="noarch"/>
> <entry kind="package" name="yast2-network" epoch="0" ver="3.0.8" rel="5.1" arch="x86_64"/>
....
YaST has, of course, a corresponding “import” menu entry.
> But probably the version indications
> are part of the package names. And for 13.1 there will most probably be
> newer versions for most packages. Thus editing the file with the list of
> packages, removing the versions and then doing zypper in on every of
> them might be a solution.
As you see, editing the file is not that easy, you need something that
can parse XML and pull out just the “name=” entries.
> But it will not help e.g. when packages changed names, where merged, or
> otherwise reorganised between the two openSUSE versions.
Yes, that’s a problem.
That, and that the file specifies versions. On the other hand, it does
not mention repo of origin, so recreating an install using the proper
packman packages, say, is quite difficult.
The feature needs some developer care.
If I had to do it (as admin, not dev), I would first create the list
using plain rpm command, with some concoction to get the appropriate
fields printed, and then use some script to generate an appropriate
zypper concoction to install that list of packages - more or less. And
I’m not confident on getting it right.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Well, wouldn’t it have been nice if the OP had told what you now told. Why expecting that others are doing this more or less every day and thus will understand immediatly what is done and what are the results?
In any case, thanks for finding out what the OP most probably did and for posting that.
I guess that that functionality is designed to make a sort of backup of the present state of the system (with respect to installed pakages), to be able to restore that situation after e.g. a disk crash and a new installation.
And when it is designed for that purpose, it will by design not serve the purpose asked for by the OP. I am not sure that this needs “some developer care” because it most probably does where it is made for.
In my post above, I already pointed to some basic problems that are to be taken care of when trying do do this more or less automatic. When packages have a new names and/or dependancy structure in the new openSUSE version, there is no automatic way to do this.
The way Carlos points to (customised rpm listing and intelligent editing and intelligent uasge of the results) is as near as you can get I am afraid.
So, would a feature like this be something that could be added to, or in conjunction with zypper dup? Although the issues hcvv brought up about renaming or merged.
Although I wonder if it captures top level application names and let the system on-the-fly determine dependencies, if that might change from release to release?
On 2014-04-25 09:46, hcvv wrote:
>
> Well, wouldn’t it have been nice if the OP had told what you now told.
> Why expecting that others are doing this more or less every day and thus
> will understand immediatly what is done and what are the results?
>
> In any case, thanks for finding out what the OP most probably did and
> for posting that.
Welcome
I happened to look at that feature some time ago, so I knew. But that’s
to be expected, some of us are familiar with some applications and some
of their features, and other people with a different set.
> I guess that that functionality is designed to make a sort of backup of
> the present state of the system (with respect to installed pakages), to
> be able to restore that situation after e.g. a disk crash and a new
> installation.
Yep.
Probably combined with autoyast.
> And when it is designed for that purpose, it will by design not serve
> the purpose asked for by the OP. I am not sure that this needs “some
> developer care” because it most probably does where it is made for.
Actually, it also fails for restore of a system, because it does not
have repository information. The feature only works if you have the
official default repositories, I’m afraid. It might have been designed
when there were no repos.
> In my post above, I already pointed to some basic problems that are to
> be taken care of when trying do do this more or less automatic. When
> packages have a new names and/or dependancy structure in the new
> openSUSE version, there is no automatic way to do this.
No, and yes. The system can ask the user. This is what the offline
upgrade procedure does, when upgrading a system to a newer release (boot
from the DVD, choose upgrade).
> The way Carlos points to (customised rpm listing and intelligent editing
> and intelligent uasge of the results) is as near as you can get I am
> afraid.
Another method that just occurred to me is to clone the original
installation on the other computer, and then upgrade it.
And another is to play with autoyast. I’m not familiar with it in order
to know if it is feasible, or this exported yast list is actually what
autoyast uses. Or, instead of the export feature, use the “system
backup” method. It does generate an autoyast profile, I understand. But
I’ve never used it for this purpose. It should work in order to
replicate the source installation, which then would have to be upgraded
to the newer release.
And I have my reservations about how it handles multiple repos - I
suspect it doesn’t handle the situation at all.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Thank you all for your responses, but let me pose the problem a different way … how did you upgrade your system before the online upgrade feature became available? (I’m assuming that at least some of you were using openSUSE prior to 12.0) After the installation was complete did you go into Yast’s Software Management, scroll through the RPM groups and patterns, and add packages one by one? Or was there another way to get all the packages you had installed in the previous version installed in the new version? (And yes, I am aware of the problem posed by apps being merged, renamed, or discontinued … but what of all the packages that weren’t?)
How did we upgrade?
I usually end up doing a clean install (/home is a separate partition) and manually re-adding the applications. The benefit of this is I can decide whether to add back some packages that I may not use, or hold off installing something until I feel I need it. The down-side is that I can (easily) forget some things (but then again, if it is truly important, I should notice something missing through the normal course of my workflow).
On 2014-04-25 15:56, pmmt wrote:
>
> Thank you all for your responses, but let me pose the problem a
> different way … how did you upgrade your system before the online
> upgrade feature became available?
Using the offline upgrade feature 
> (I’m assuming that at least some of
> you were using openSUSE prior to 12.0)
Indeed. 5.3. This system has been upgraded from there, in steps, and
with hiccups and hardware migrations.
> After the installation was
> complete did you go into Yast’s Software Management, scroll through the
> RPM groups and patterns, and add packages one by one? Or was there
> another way to get all the packages you had installed in the previous
> version installed in the new version? (And yes, I am aware of the
> problem posed by apps being merged, renamed, or discontinued … but
> what of all the packages that weren’t?)
The method I use is clone the system, boot it, check hardware changes,
then upgrade it. After that, apply the multimedia procedure as usual,
and add extra repos as needed.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-04-25 16:26, dragonbite wrote:
> How did we upgrade?
>
> I usually end up doing a clean install (/home is a separate partition)
> and manually re-adding the applications.
Many did that. But it is a chore to have to re-add manually all the
applications and services you had in the previous version, instead of
being able to import a list automatically, or at lest semi automatically.
The possibilities would be:
· non existing package.
· package available on several repos, choose one.
· postpone package dependency solving (not ignore, postpone).
Reason: the conflict can solve itself when adding another
package further down in the list.
And you have to be able to stop, add new repos, postpone decision in
order to think or ask in forum…
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
It could be mildly improved by keeping a script for installing applications and update it when you add something new. Keep the script generic enough and save it in your /home directory. Can even include adding the repos first.
Can even add copying or updating config files and some customizations.
Not ideal, and tedious but could help in some people’s circumstances.
Same here as Dragonbite. Clean install, keep /home. Add packages. My installation plan has a list of packages not to install and to install at system installation (e.g. do not install Apper and PackageManager and install LAMP pattern on system A, etc., not realy a long list).
I see installation of a new version as an opportunity to clean up things. And I skip versions (as long as the used one is still supported) because I love stability.
Maybe I miss some of the installed ones, but those can’t be to important and easy to add when I find out after a month that I need one.
BTW, I do have a list of installed RPMs (fresh created every week), which I can consult. And I keep the former used system on it’s root partition for some time after I installed a new system on its own root partition. Thus I can allways mount that and see what is on it (ver nice to look in old /etc config files e.g.).
Does that mean you keep a partition with the old version and a partition with the new (current) version and only boot into current one but can mount and view the other partition?
Yes, I even have my old /home. That means that I can install the new version first with an up-to-date copy of /home and can then test. On the real switchover, I make e fresh copy of /home and from then on allways use the new system. But I can still look into older files of the former /home. That is not so much beause of the new system, as well because of new applications like KDE.
henk@boven:~> cat /etc/fstab
/dev/disk/by-id/ata-Hitachi_HDT725032VLA380_VFJ201R23XUEXW-part2 / ext4 acl,user_xattr 1 1
/dev/disk/by-id/ata-Hitachi_HDT725032VLA380_VFJ201R23XUEXW-part1 swap swap defaults 0 0
/dev/disk/by-id/ata-Hitachi_HDT725032VLA380_VFJ201R23XUEXW-part3 /home ext4 defaults 1 2
/dev/disk/by-id/ata-Hitachi_HDT725032VLA380_VFJ201R23XUEXW-part5 /mnt/B ext4 ro,acl 1 2
/dev/disk/by-id/ata-Hitachi_HDT725032VLA380_VFJ201R23XUEXW-part6 /mnt/B/home ext4 ro,acl 1 2
henk@boven:~>
I called the systems A and B and labeled the file systems System_A, System_B, Home_A and Home_B top prevent mistakes. At the moment openSUSE 13.1 is on A and I have B available at /mnt/B/ when it is running. Grub of course also allows me to boot B directly.
Now at this moment in time I am running 13.1 since january, thus I do not realy need to keep B anymore. First step could be to remove the fstab entries. Second step to remove the entry from Grub.
Until a new switchover 
I have 2 root partitions and alternate them between version doing a clean install. Clean out the fluff that I accumulate and reinstalling most apps doesn’t take that much time I install what I remember at first then install as I need. Two roots so I can install and be sure that the new version is stable on my hardware before moving my home mount to the new install
On 2014-04-25 17:06, dragonbite wrote:
>
> It could be mildly improved by keeping a script for installing
> applications and update it when you add something new. Keep the script
> generic enough and save it in your /home directory. Can even include
> adding the repos first.
Yes… I have considered that many times. Besides packages to add, I
have my pet scripts that I need, services I add, modifications, etc.
Yes, indeed, it is on my ToDo list, but I forgot.
I would also need to call yast to do some modifications, so if YaST were
“scriptable”, it would be a bonus. Otherwise… just start the
appropriate yast module and pop up a message with instructions.
Sigh… A lot of things to do on it.
> Can even add copying or updating config files and some customizations.
>
> Not ideal, and tedious but could help in some people’s circumstances.
Drooling already… :-)~~~
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-04-25 17:26, dragonbite wrote:
>
> hcvv;2639162 Wrote:
>> And I keep the former used system on it’s root partition for some time
>> after I installed a new system on its own root partition. Thus I can
>> allways mount that and see what is on it (ver nice to look in old /etc
>> config files e.g.).
>
> Does that mean you keep a partition with the old version and a partition
> with the new (current) version and only boot into current one but can
> mount and view the other partition?
That’s a typical thing to do, specially on server type systems. It is
the cheap version of actually having two computers: prepare the other
one as replacement, then switch over on the DNS and dhcp or internal
fixed IP. A year or two later, repeat cycle.
With the added advantage of having an standby replacement.
Some other people replace the HD…
Each admin has their favourites
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-04-25 18:56, gogalthorp wrote:
>
> I have 2 root partitions and alternate them between version doing a
> clean install. Clean out the fluff that I accumulate and reinstalling
> most apps doesn’t take that much time I install what I remember at
> first then install as I need. Two roots so I can install and be sure
> that the new version is stable on my hardware before moving my home
> mount to the new install
I have several root partitions. One is the main system, the rest are
test partitions. I typically test the new version, preferably when it is
still on “factory”, installed fresh, on one of them. When satisfied, I
upgrade (offline) the main one.
If something does not work after the upgrade, I can compare with the
test partition. If the main system needs offline maintenance, I have a
spare system.
I had a trick to do a “zypper dup” on the test partition, chrooted from
the main system; instead of booting the test partition, run the dup,
which can mean wait hours, with my slow internet.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
With our public website (at work) we have 2 servers in different locations for failover. Right now I am working on upgrading the (Drupal) website on the secondary system and if that works we failover so actual traffic goes to the updated server instead and if there is a problem we can flop it back to the old one.