[pacman-dev] epoch (was: Chat with toofishes at jabber.org)
chantry.xavier at gmail.com
Sat Oct 30 15:08:21 EDT 2010
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 :
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)
More information about the pacman-dev