Hi all,
i'm using external repository with various vendor supplied rpm's in koji. One of those rpm's had it's versioning schema changed and it uses epoch tag now. After regeneration of the build tags koji does not see the new package. It looks like mergerepos ignores the epoch tag. The "old" rpm which actually has a higher version number if epoch is not considered is included instead. Can you offer any advice? Thanks
-- BR Atanas
i'm using external repository with various vendor supplied rpm's in koji. One of those rpm's had it's versioning schema changed and it uses epoch tag now. After regeneration of the build tags koji does not see the new package. It looks like mergerepos ignores the epoch tag. The "old" rpm which actually has a higher version number if epoch is not considered is included instead. Can you offer any advice?
Hi Atanas,
Have you tried the latest: http://koji.fedoraproject.org/koji/buildinfo?buildID=605087
For me, mergerepo (from EPEL 7) was broken. I was experiencing this: https://bugzilla.redhat.com/show_bug.cgi?id=1058975
/allen
________________________________
Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender.
On Friday, January 30, 2015 10:29:37 PM Allen Hewes wrote:
i'm using external repository with various vendor supplied rpm's in koji. One of those rpm's had it's versioning schema changed and it uses epoch tag now. After regeneration of the build tags koji does not see the new package. It looks like mergerepos ignores the epoch tag. The "old" rpm which actually has a higher version number if epoch is not considered is included instead. Can you offer any advice?
Hi Atanas,
Have you tried the latest: http://koji.fedoraproject.org/koji/buildinfo?buildID=605087
For me, mergerepo (from EPEL 7) was broken. I was experiencing this: https://bugzilla.redhat.com/show_bug.cgi?id=1058975
/allen
Hi Allen,
thanks for the pointers but it seems that's not it. Koji actually executes /usr/libexec/kojid/mergerepos which is provided by the package koji-builder. createrepo package provides /usr/bin/mergerepo. So koji has its own mergerepo command.
I ran /usr/bin/mergerepo manually and the generated metadata did have the new package with the epoch tag. A bug in koji's version of mergerepos maybe?
This is with koji 1.8.0 running on RHEL6.
-- BR Atanas
On 01/30/2015 02:05 PM, Atanas Zhelev wrote:
i'm using external repository with various vendor supplied rpm's in koji. One of those rpm's had it's versioning schema changed and it uses epoch tag now. After regeneration of the build tags koji does not see the new package. It looks like mergerepos ignores the epoch tag. The "old" rpm which actually has a higher version number if epoch is not considered is included instead. Can you offer any advice? Thanks
There is nowhere in koji where newer-nvr automatically wins. This would make it impossible to perform many overrides by tagging. Instead the winner (within koji tags at least) is determined my depth in inheritance chain and how recently the build was tagged.
Also, all builds are handled as a unit, so you will never see mixing of subpackages from two different versions of the same build, even if newest NVR might indicate otherwise.
When koji merges an external repo it tries to be consistent with the the its behavior in the non-external-repo case. In particular,
* koji's package block list is honored by mergerepos * rpms in the external repo are grouped by their srpm and treated as a unit when filtering/merging * only one srpm nvr per package is kept * for packages existing /only/ in the external repo, e:nvr ordering is followed * content within koji trumps the external repo content
On Wednesday, February 04, 2015 06:08:28 AM Mike McLean wrote:
On 01/30/2015 02:05 PM, Atanas Zhelev wrote:
i'm using external repository with various vendor supplied rpm's in koji. One of those rpm's had it's versioning schema changed and it uses epoch tag now. After regeneration of the build tags koji does not see the new package. It looks like mergerepos ignores the epoch tag. The "old" rpm which actually has a higher version number if epoch is not considered is included instead. Can you offer any advice? Thanks
There is nowhere in koji where newer-nvr automatically wins. This would make it impossible to perform many overrides by tagging. Instead the winner (within koji tags at least) is determined my depth in inheritance chain and how recently the build was tagged.
Also, all builds are handled as a unit, so you will never see mixing of subpackages from two different versions of the same build, even if newest NVR might indicate otherwise.
When koji merges an external repo it tries to be consistent with the the its behavior in the non-external-repo case. In particular,
- koji's package block list is honored by mergerepos
- rpms in the external repo are grouped by their srpm and treated as a
unit when filtering/merging
- only one srpm nvr per package is kept
- for packages existing /only/ in the external repo, e:nvr ordering is
followed
- content within koji trumps the external repo content
Hi Mike,
in my case the packages in question exists /only/ in the external repository and nowhere else. There are no srpms of these packages.
I have: foo-2012.06.23-1.rpm /no epoch tag/ foo-1.8-1.rpm /epoch = 1/
The repo metadata after koji has merged the external repository contains foo-2012.06.23-1.rpm while i would expect that foo-1.8-1.rpm is in.
-- BR Atanas
On 02/05/2015 12:07 PM, Atanas Zhelev wrote:
On Wednesday, February 04, 2015 06:08:28 AM Mike McLean wrote:
On 01/30/2015 02:05 PM, Atanas Zhelev wrote:
i'm using external repository with various vendor supplied rpm's in koji. One of those rpm's had it's versioning schema changed and it uses epoch tag now. After regeneration of the build tags koji does not see the new package. It looks like mergerepos ignores the epoch tag. The "old" rpm which actually has a higher version number if epoch is not considered is included instead. Can you offer any advice? Thanks
There is nowhere in koji where newer-nvr automatically wins. This would make it impossible to perform many overrides by tagging. Instead the winner (within koji tags at least) is determined my depth in inheritance chain and how recently the build was tagged.
Also, all builds are handled as a unit, so you will never see mixing of subpackages from two different versions of the same build, even if newest NVR might indicate otherwise.
When koji merges an external repo it tries to be consistent with the the its behavior in the non-external-repo case. In particular,
- koji's package block list is honored by mergerepos
- rpms in the external repo are grouped by their srpm and treated as a
unit when filtering/merging
- only one srpm nvr per package is kept
- for packages existing /only/ in the external repo, e:nvr ordering is
followed
- content within koji trumps the external repo content
Hi Mike,
in my case the packages in question exists /only/ in the external repository and nowhere else. There are no srpms of these packages.
I have: foo-2012.06.23-1.rpm /no epoch tag/ foo-1.8-1.rpm /epoch = 1/
The repo metadata after koji has merged the external repository contains foo-2012.06.23-1.rpm while i would expect that foo-1.8-1.rpm is in.
In addition to koji content trumping external repo content, the external repos trump each other based on priority when there is more than one external repo. Perhaps you should just adjust the priorities of your external repos.
Unfortunately it looks like edit-external-repo cannot do this, so you'll want to remove it from the tag and re-add it with a different priority. Note that the lower number == higher priority (like with nice).
-- BR Atanas -- buildsys mailing list buildsys@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/buildsys
buildsys@lists.fedoraproject.org