> Nagy and I discussed a bit that topic. > Don't we already read all local depends file for conflict and/or dep > checking ? > So this means we'll now read all local depends + all desc files ? > Why not put epoch stuff in the local depends file then ? > > IIRC there has been a plan for years to move replaces and force from > depends to desc, probably for sync db? and for similar reasons, but > no one ever dared to do it. > > Another crazy thought, since epoch is really just a version > extension, why not define it as a version prefix or something ? > 3.5.0 < 2#3.4 < 3#2.0 > or whatever crazy syntax we can come up with. Then we just need to > have vercmp support that, and that's all, nothing complex to do in > any database.
I prefer this tricky solution. Logically, epoch is an extension of the version number, so this doesn't even seem too hackish. And I would completely drop %FORCE% without backward compatibility to eliminate the need for reading db to get epoch. When %FORCE% doesn't work, pacman just won't upgrade some packages with -Su, and since our crucial packages (pacman, glibc etc.) has no force and versioned dependencies are used, this is not a big deal. Of course, in arch news this force->epoch change should be mentioned (to AUR packagers). Alternative solution: db rewrite. ;-) > I am sorry this comes up a bit late, but only git code has been > touched and no harm has been made as far as I know, I just want to be > sure that we carefully considered all possible solutions for the > stupid versioning some projects use, and that we indeed chose the > best way (epoch is probably alright and better than force), but also > the best implementation.