Re: Specfile - Upgrade - Check if the old and the new package versions are the same

[Simon Pichugin <spichugi@xxxxxxxxxx>]

Hi folks,

Thank you for the answers!

On Thu, Mar 30, 2023 at 1:16 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:

I wonder what the "do something" is, because comparing versions is almost always the wrong choice IMHO.

When the server package upgrades to the next major version, there are upgrade instructions that need to be performed by the administrator.
And what's most important, the server should not start automatically without explicit agreement from the administrator.

But we don't need to do that when the package upgrade happens with just a release number bump (2.6.4-1 -> 2.6.4-2).
That's what I'm trying to solve with the RPM tools. 

BTW there are "vercmp(v1, v2)" and "ver(evr), ver(e, v, r)" Lua functions for EVR comparisons.

I'll check it out. Thanks!

On Thu, Mar 30, 2023 at 3:14 AM Miroslav Suchý <msuchy@xxxxxxxxxx> wrote:

I second Vít. Comparing version is wrong approach. IMO.

1) it is definitelly bad idea if you call `rpm -qa` because rpm is not reentrant. So calling rpm from scriptlet may work, but one day it will do something really bad.

2) you did not take in consideration epoch. So it may cause you a problem few years in future.

3) such decision should be always based on capabilities. Does such config exists? Is some variable in config set? Or not set?

In your case, I would check for existence of /etc/openldap/migrated_from_version_1 file. And if it does not exist then do the migration and when done, touch this file. And you should own this file as %ghost.

It looks like a great fit for my situation! The only downside I can see it's if the administrator will remove the file.

And then, when he needs to upgrade, we won't be able to tell if it's a major or minor upgrade. But it's really minor and can be worked out, I think.
Thank you! I'll look into that option, and we'll see how it goes. :)

Regards,

Simon

Miroslav

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue