Re: [pacman-dev] Chat with toofishes@jabber.org
On Fri, Oct 8, 2010 at 7:06 PM, toofishes@jabber.org <toofishes@jabber.org>wrote:
5:48 PM me: waoh, where does this come from ? :) what made you implement epoch ? toofishes: the stupid bug reports clicked on one and went "ok we have three of these lets fix this shit" 5:49 PM it ended up not even being that much change, which was nice had to fix a few things after running tests and such, but overall pretty straightforward me: what was hard ? keep support for force ? 5:50 PM toofishes: yeah ensuring both forward/backward support 5:51 PM me: the result looks pretty good and natural toofishes: yeah and eventually some of it can be cleaned up can you spot the one drawback from this though? i didn't catch it at first, had to go back and fix my patch you will laugh because you were talking about it the other day. 5:52 PM me: give me a hint, is it pacman related or makepkg/repo-add toofishes: pacman database releated 5:56 PM me: damn I cannot see, looking at the patch in be_files.c . and last thing I remember discussing about database was sanity check. maybe bogus epoch values or something force was just on/off toofishes: no we didn't have to read every desc file before but now we do to always get the epoch value back 5:58 PM me: damn I actually spotted the vercmp call and force/epoch was in a different order but I just thought force definitely looked weird 5:59 PM ok I mentioned slow db too, I never considered this depends/desc thing really. nagy mentioned it many times though and I thought we were already fucked toofishes: yeah we just need to redo the db, tahts all :)
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 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.
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.
On Mon, Oct 25, 2010 at 1:03 PM, Nagy Gabor <ngaba@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)
On 31/10/10 05:08, Xavier Chantry wrote:
On Mon, Oct 25, 2010 at 1:03 PM, Nagy Gabor<ngaba@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)
That is because none of the packages know about epoch yet. You are going to have to manually update packages that use the force flag for the time being. BTW, the db update in [testing] has epoch=1 as the db-4.9 package had a force value, so you should be able to update that. Alan
On Sat, Oct 30, 2010 at 11:26 PM, Allan McRae <allan@archlinux.org> wrote:
That is because none of the packages know about epoch yet. You are going to have to manually update packages that use the force flag for the time being.
BTW, the db update in [testing] has epoch=1 as the db-4.9 package had a force value, so you should be able to update that.
Since force is simply interpreted as epoch=1, sane version bumps of force packages should work (as was the case with xpdf). But now that you point it out, insane version changes would not work indeed, that's the ones which would require an epoch bump. Anyway I was just pointing out that when a package has epoch=1, it can not be dropped. Which implies that force cannot be dropped, but only kept or replaced by epoch=1 or higher.
participants (3)
-
Allan McRae
-
Nagy Gabor
-
Xavier Chantry