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.

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

Find a way to prevent installation of fc13 rpms on f14 and vice vers #197

Closed
marmarek opened this Issue Mar 8, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@marmarek
Member

marmarek commented Mar 8, 2015

Reported by joanna on 5 Apr 2011 22:03 UTC
I have just upload new gui-vm package compiled on F13 (so it has .fc13 extension) to our vm unstable repo. When I launched the yum update in VM based on F14 the packet was happily picked and installed. As a result the gui stopped working :/

I think we would like to maintain VM packages for both F13 and F14, and this behaviour is very problematic for us...

Migrated-From: https://wiki.qubes-os.org/ticket/197

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 5 Apr 2011 22:23 UTC
One might think that if we provided both .fc14 and .fc14 versions of the same packet (i.e. with the same version/rel), then yum would intelligently choose the proper packet (if running on F13 would chose .fc13, etc). But this is not how it works -- yum always greedily chooses the hightest numbered packet, so in that case the .fc14 will always be chosen on both F14 as well as on F13.

Any ideas better than having to maintain two different repos?

Member

marmarek commented Mar 8, 2015

Comment by joanna on 5 Apr 2011 22:23 UTC
One might think that if we provided both .fc14 and .fc14 versions of the same packet (i.e. with the same version/rel), then yum would intelligently choose the proper packet (if running on F13 would chose .fc13, etc). But this is not how it works -- yum always greedily chooses the hightest numbered packet, so in that case the .fc14 will always be chosen on both F14 as well as on F13.

Any ideas better than having to maintain two different repos?

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 6 Apr 2011 07:50 UTC
Ok, I'm pretty determined to split the VM repo into two:

.../current/vm/f13
.../current/vm/f14
.../unstable/vm/f13
.../unstable/vm/f14

Will also require changes to core-commonvm rpm, and to some Makefiles to automatically copy rpms to appropriate repo based on the suffic.

Member

marmarek commented Mar 8, 2015

Comment by joanna on 6 Apr 2011 07:50 UTC
Ok, I'm pretty determined to split the VM repo into two:

.../current/vm/f13
.../current/vm/f14
.../unstable/vm/f13
.../unstable/vm/f14

Will also require changes to core-commonvm rpm, and to some Makefiles to automatically copy rpms to appropriate repo based on the suffic.

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Modified by joanna on 6 Apr 2011 10:52 UTC

Member

marmarek commented Mar 8, 2015

Modified by joanna on 6 Apr 2011 10:52 UTC

@marmarek marmarek closed this Mar 8, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment