Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

The tito build --{s,}rpm --test should have higher NVR than the system wide package #460

Closed
praiskup opened this issue Jun 21, 2023 · 4 comments · Fixed by #502
Closed

The tito build --{s,}rpm --test should have higher NVR than the system wide package #460

praiskup opened this issue Jun 21, 2023 · 4 comments · Fixed by #502
Labels
effort/medium Can be done in 1-2 days gain/high Significantly moves the project forward RFE This issue is a Request For Enhancement (Feature)

Comments

@praiskup
Copy link
Member

praiskup commented Jun 21, 2023 •
edited
Loading

The typical problem I have:

  1. Package Foo with Version: 1.1 and Release: 1 is tagged to
    upstream git, and released (to Fedora)

  2. Then tito build --test ... works fine because the generated release
    looks like 1.git.3548.f7f3934. This is fine, because:

    $ rpmdev-vercmp 1.1-1.git.3548.f7f3934 1.1-1
1.1-1.git.3548.f7f3934 > 1.1-1

    IOW, the package with --test has a higher NVR than the one in Fedora.

  3. After some time, the Fedora package gets an asynchronous update by
    Fedora community, bumping Release: 2 (rebuild for GCC bump, e.g.)

  4. The --test package still provides the same NVR with
    1.1-1.git.3548.f7f3934 which is though:

    $ rpmdev-vercmp 1.1-1.git.3548.f7f3934 1.1-2
1.1-1.git.3548.f7f3934 < 1.1-2

If the --test package is e.g. built n Copr, or locally, it doesn't easily update
the one installed on the system which complicates testing.

I'm not saying now how to resolve this, or whether we should do it by
default. But it would be nice to have a way to provide a higher NVR than
the one in Fedora somehow. E.g. by bumping the Version? Bumping Release
to 666? I don't know.
@praiskup praiskup added the RFE This issue is a Request For Enhancement (Feature) label Jun 21, 2023
praiskup added a commit to praiskup/mock that referenced this issue Jun 29, 2023
@praiskup
Post-release administrivia
83ce4b6 
The 'postX' Version tag allows us to explicitly require a specific
pre-release version of mock in a pre-release mock-core-configs Version.
The tag can be bumped during the development according to the actual
needs.

This way of version handling is also a way-around the missing Tito RFE:
rpm-software-management/tito#460
praiskup added a commit to praiskup/mock that referenced this issue Jun 29, 2023
@praiskup
Post-release administrivia
11e061d 
The 'postX' Version tag allows us to explicitly require a specific
pre-release version of mock in a pre-release mock-core-configs Version.
The tag can be bumped during the development according to the actual
needs.

This way of version handling is also a way-around the missing Tito RFE:
rpm-software-management/tito#460
@praiskup praiskup mentioned this issue Jun 29, 2023
Merged
praiskup added a commit to praiskup/mock that referenced this issue Jun 30, 2023
@praiskup
Post-release administrivia
4e94c87 
The 'postX' Version tag allows us to explicitly require a specific
pre-release version of mock in a pre-release mock-core-configs Version.
The tag can be bumped during the development according to the actual
needs.

This way of version handling is also a way-around the missing Tito RFE:
rpm-software-management/tito#460
xsuchy pushed a commit to rpm-software-management/mock that referenced this issue Jul 17, 2023
@praiskup @xsuchy
Post-release administrivia
6971d98 
The 'postX' Version tag allows us to explicitly require a specific
pre-release version of mock in a pre-release mock-core-configs Version.
The tag can be bumped during the development according to the actual
needs.

This way of version handling is also a way-around the missing Tito RFE:
rpm-software-management/tito#460
@praiskup praiskup mentioned this issue Oct 25, 2023
Merged
@FrostyX FrostyX added effort/medium Can be done in 1-2 days gain/high Significantly moves the project forward labels Jan 1, 2024
@praiskup praiskup moved this to Needs triage in CPT Kanban Jan 5, 2024
@praiskup
Copy link
Member Author

praiskup commented Jan 5, 2024

FWIW, tito project itself has the problem now:

$ sudo dnf copr enable @rpm-software-management/tito
$ sudo dnf update tito
...nothing happens...

the version in Copr is 0.6.24-1.fc39 compared to system default 0.6.24-2.fc39

@praiskup praiskup mentioned this issue Jan 5, 2024
Closed
@praiskup praiskup moved this from Needs triage to In 2 years in CPT Kanban Jan 10, 2024
@FrostyX
Copy link
Member

FrostyX commented Jan 12, 2024

Thinking out loud ... so, can we simply automatize the same thing that #480 did? When using --test, tito would add the .post1 suffix for the version? The suffix could be optional (opt-out probably) and configurable.

@praiskup
Copy link
Member Author

For me, this is hard to predict. Can we simply try that? Seems like a nice experiment.

@praiskup
Copy link
Member Author

Just tried to chain build the client Copr packages from git-head:

mock --chain \
/tmp/tito/python-copr-1.132-1.git.75.658230d.fc41.src.rpm \
/tmp/tito/copr-cli-1.112-1.git.78.658230d.fc41.src.rpm

But for the copr-cli package it always installs:

python3-copr                         noarch 1.132-3.fc41           fedora     241.8 KiB

praiskup added a commit to praiskup/tito that referenced this issue Sep 27, 2024
@praiskup
New option test_version_suffix
f644cab 
If configured like

    $ cat .tito/tito.props
    [buildconfig]
    test_version_suffix = .tito.git

The `tito build --test ...` NEVRA is always higher than the NEVRA of
released RPMs.

Fixes: rpm-software-management#460
praiskup added a commit to praiskup/tito that referenced this issue Sep 27, 2024
@praiskup
New config option buildconfig.test_version_suffix
9069fc1 
If configured like

    $ cat .tito/tito.props
    [buildconfig]
    test_version_suffix = .tito.git

The `tito build --test ...` NEVRA is always higher than the NEVRA of
released RPMs.

Fixes: rpm-software-management#460
@praiskup praiskup mentioned this issue Sep 27, 2024
Merged
praiskup added a commit to praiskup/tito that referenced this issue Sep 30, 2024
@praiskup
New config option buildconfig.test_version_suffix
2860fef 
If configured like

    $ cat .tito/tito.props
    [buildconfig]
    test_version_suffix = .tito.git

The `tito build --test ...` NEVRA is always higher than the NEVRA of
released RPMs.

Fixes: rpm-software-management#460
@FrostyX FrostyX closed this as completed in 6183892 Oct 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
effort/medium Can be done in 1-2 days gain/high Significantly moves the project forward RFE This issue is a Request For Enhancement (Feature)
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

New config option buildconfig.test_version_suffix praiskup/tito
2 participants
@FrostyX @praiskup