As some of you already noticed, when updating the RPM package (using rpm -U), the shortcuts in the Gnome and KDE menus are lost. This is not coming out of NeroLINUX but more from a RPM problem... and does not affect the Debian package
I explain: When you update, the post-installation script that creates the shortcuts is executed. Afterwards, the pre-uninstallation script of the old package is then executed, and removed the fresh-created menu shortcuts... that's why they are no more available.

So for RPM packages, you should uninstall them completly (rpm -e) and install the new one after. This will not affect your configuration file.

I've got experience with this RPM upgrade oddity. If anyone from Nero is reading this, you need to wrap all your %pre, %post, %preun, and %postun sections of your RPM .spec file to check the $1 variable to see if an upgrade is happening.

As some of you already noticed, when updating the RPM package (using rpm -U), the shortcuts in the Gnome and KDE menus are lost. This is not coming out of NeroLINUX but more from a RPM problem... and does not affect the Debian package

No, it is not an RPM problem, it's yours and it is very easy to fix. Please let me explain and then fix it because NeroLINUX is at the moment packaged wrong, sorry.

Quote:

Originally Posted by mathf

As some of you already noticed, when updating the RPM package (using rpm -U), the shortcuts in the Gnome and KDE menus are lost. This is not coming out of NeroLINUX but more from a RPM problem... and does not affect the Debian package
I explain: When you update, the post-installation script that creates the shortcuts is executed. Afterwards, the pre-uninstallation script of the old package is then executed, and removed the fresh-created menu shortcuts... that's why they are no more available.

This is a matter of reading the RPM documentation. There is a solution and a workaround which works without reading any documentation.

First, the workaround. Simply append the version string to the names of the generated files. So, create nero-2.0.0.2.png and nero-2.0.0.2.desktop instead of just nero.png and nero.desktop. This way, RPM will create nero-2.0.0.2.png and nero-2.0.0.2.desktop and afterwards remove nero-2.0.0.1.png and 2.0.0.1.desktop.

And now the real solution. Every %pre, %post, %preun and %postun script in an RPM is passed exactly one command-line parameter. This parameter ist, as for every shell script, available as the environment variable $1. The parameter contains the number of instances of the package they belong to that will be present after the current action has finished.

In detail. If a package is installed, the number of instances that are present is 1. Therefore, %pre and %post are passed the parameter "1" at first install; %preun and %postun are not executed at all. If a package is updated, the number of instances for %pre and %post is 2, one that whose installation happens right now and that will be erased immediately after.

But for %preun and %postun, the parameter is "1" because these are executed after the old package was already removed. Therefore, during an upgrade %pre and %post are passed the parameter "2" and %preun and %postun are passed the parameter "1".

If a package is removed, %pre and %post are not executed at all. %preun and %postun are executed after the removal of the last remainung package. Therefore, both are passed the parameter "0" during removal.

This is all you need to know. Simply introduce a check into your scripts so that it looks like this:

This way, your %pre and %post scripts are only executed at first install and not during upgrades. %preun and %postun are only executed at removal and not during upgrades, either. In other words, nothing is done during upgrades. Of course, you can leave the check out for %pre and %post if you prefer that the menu entries are regenerated even when upgrading. The only important thing is that you include the check in %preun and %postun.

More information about these things is described at IBM developerworks:

Please fix this bug, it's yours. It's a well-known fact that RPM has a very bad reputation, but a large part of the problems are very easy to fix and actually depend on developer's willingness to read the documentation carefully.

EDIT: Please forgive me. I asked you to read more carefully, but myself I didn't even read the thread and the fact that the problem was already solved - sorry. I'm very ashamed.

No need for shame! From a NON-Developer-persepctive (myself) this was VERY helpful in understanding a little more on how the update process works, as I have always been a little mystified by RPM. I have had VERY little trouble with rpm and don't know WHY it has such a bad reputation since it's worked well for me...obviously because the developers "did it right" and all of it worked correctly. Cool.