FS#24696 - [grub2-bios]: in [testing] file conflict

Attached to Project: Arch Linux
Opened by mark (mmm) - Sunday, 12 June 2011, 14:32 GMT
Last edited by Ronald van Haren (pressh) - Monday, 13 June 2011, 14:19 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Ronald van Haren (pressh)
Dan McGee (toofishes)
Allan McRae (Allan)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Hello,
there's a file conflict in grub2:
yaourt -Syu

error: failed to prepare transaction (could not satisfy dependencies)
:: Starting full system upgrade...
:: grub2-bios: requires grub2-common=1.99

and

$ yaourt -S grub2-bios
resolving dependencies...
warning: cannot resolve "grub2-common=1.99", a dependency of "grub2-bios"
:: The following package cannot be upgraded due to unresolvable dependencies:
grub2-bios


which is weird as:

1 testing/grub2-bios 1:1.99-2 [0.63 M] [installed: 1.99~rc2.r3238-1]
The GNU GRand Unified Bootloader version 2 - Built for PC BIOS
2 testing/grub2-common 1:1.99-2 [1.21 M] [installed: 1.99~rc2.r3238-1]
The GNU GRand Unified Bootloader version 2 - Files common for all platforms
3 testing/grub2-efi-i386 1:1.99-2 [0.62 M]
The GNU GRand Unified Bootloader version 2 - i386 UEFI version
4 testing/grub2-efi-x86_64 1:1.99-1 [0.62 M]
The GNU GRand Unified Bootloader version 2 - x86_64 UEFI version
5 extra/grub2-bios 1.99~rc2.r3238-1 [0.63 M] [installed]
The GNU GRand Unified Bootloader version 2 - Built for PC BIOS
6 extra/grub2-common 1.99~rc2.r3238-1 [1.11 M] [installed]
The GNU GRand Unified Bootloader version 2 - Files common for all platforms
7 extra/grub2-efi-i386 1.99~rc2.r3238-1 [0.62 M]
The GNU GRand Unified Bootloader version 2 - i386 UEFI version
8 extra/grub2-efi-x86_64 1.99~rc2.r3238-1 [0.62 M]
The GNU GRand Unified Bootloader version 2 - x86_64 UEFI version



thanks, Mark
This task depends upon

Closed by  Ronald van Haren (pressh)
Monday, 13 June 2011, 14:19 GMT
Reason for closing:  Fixed
Additional comments about closing:  1:1.99-3
Comment by Ronald van Haren (pressh) - Monday, 13 June 2011, 07:18 GMT
after setting dependency on grub2-common=${epoch}:${pkgver} it seems to work after local testing in the new version I just uploaded
Comment by Ronald van Haren (pressh) - Monday, 13 June 2011, 07:21 GMT
Dan/Allan is that the intended pacman behavior? Seems a bit confusing when you have to specify such a thing from another package.
Comment by Anonymous Submitter - Monday, 13 June 2011, 08:08 GMT
grub2-common=${epoch}:${pkgver} seems like pacman considers the pkgver to be 1:1.99 instead of 1.99 with epoch=1 . Seems like pacman fails to separate epoch value from pkgver.
Comment by Dan McGee (toofishes) - Monday, 13 June 2011, 13:05 GMT
Ronald and Keshav, I'm not sure what you're saying here regarding taking epoch into account?

1. Epoch, once incremented, takes precedence over everything else, and is an integral part of the verison number. 1.99 *never ever ever* provides 1:1.99. Ever.
2. Please narrow this report down to a case we can all grasp without having to go digging through packages that may or may not even be in the official repos. Specifying all version numbers and PKGBUILD variables in play helps; attaching minimal PKGBUILD examples helps as well too.
Comment by mark (mmm) - Monday, 13 June 2011, 13:36 GMT
ok, the problems were that:
grub2-bios and -common were bumped to epoch 1 (1:1.99), while dependency stayed at epoch 0 (1.99).
With rebuild 3 is this fixed.
The remaining problem is, that rebuild 3 is in extra while rebuild 2 (bugged) remains in testing which is of higher preference, so pkg doesnt upgrade with -Su. Please remove build 2 from testing to fix.

Also, I understand Ronald's questin that:
If/Why does pacman honor epoch in dependency versions? Like..PKGBUILD_A: depends=(pkgB-1.0),
Maintainer B tries pkgB 1.1, but realises it broken, so uses epoch to smooth "downgrade" back to 1.0 (1:1.0).
Problem is, why would you have to edit your (A) pkgbuild if version stays back at 1.0, just epoch changed?

Regards, mark
Comment by Dan McGee (toofishes) - Monday, 13 June 2011, 14:09 GMT
Because epoch is an integral part of the package version. Either 1) don't release broken packages that you may need to later version decrement (something is seriously wrong upstream if they are releasing code they insist on releasing but later have to pull out of the repos) or 2) don't split the package or 3) do the necessary rebuild.
Comment by mark (mmm) - Monday, 13 June 2011, 14:14 GMT
good, that makes sence, thanks. Then everything is clear.
Comment by Ronald van Haren (pressh) - Monday, 13 June 2011, 14:19 GMT
Okay, that answers my question if it was the intended behavior. I stupidly used the official 1.99~rc2 release name for the previous build which is obviously newer than 1.99 according to pacman, hence the epoch=1. I was just confused that I had to specify the epoch in the dependency array, but no problem if that is how it is suppose to work.

Now I only need to remove the old package as somehow both packages are now in testing. Thanks.

Loading...