[pacman-dev] epoch (was: Chat with toofishes at jabber.org)

[Xavier Chantry]

On Mon, Oct 25, 2010 at 1:03 PM, Nagy Gabor <ngaba at bibl.u-szeged.hu> wrote:
>> 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. ;-)
>

Not really a problem, but just wanted to mention something I just
spotted in today -Su.
xpdf had force flag, and was installed with pacman-epoch so local db
entry had EPOCH=1
Now the versions were sane enough, so xpdf update dropped the force flag :
http://repos.archlinux.org/wsvn/packages?op=comp&compare[]=/xpdf/trunk@58377&compare[]=/xpdf/trunk@96666

This works just fine with pacman 3.4 but not with pacman-epoch.

:: Starting full system upgrade...
warning: xpdf: local (3.02_pl4-2) is newer than extra (3.02_pl5-1)