This has outlived its usefulness and causes more problems than it solves.
Signed-off-by: Dan McGee <dan@archlinux.org> ---
This is an RFC first of all, so please feel free to comment.
Pros: 1. Removes complexity and a fair amount of code. 2. Removes the hack necesary for download-only and print operations. 3. Closes at least two bug reports. 4. Pacman is now much more resiliant to updates to itself since vercmp is statically linked, etc. so updating it alone isn't always necessary.
Cons: 1. If a major underlying change occurs (such as a new compression format), users would need to update pacman explicitly first. 2. ???
Well, I don't really like SyncFirst neither, but if we don't want to maintain a "package manager from the garage", something like SyncFirst is needed imho. Personally I don't like news in www.archlinux.org about pacman limitations (please manually do this and this), and removing SyncFirst could increase the number of such news. Btw, maybe this whole SyncFirst concept is an overkill. What we really need is in fact some kind of "database trigger", which can be recorded in sync db. Something like this: if(local_version(pacman)<=3.5) then syncfirst(pacman), otherwise the database changes can cause some (serious) headaches. I would be happy if "manual intervention required" www news could be printed by pacman in the future somehow in a similar way. Of course, this way is also hackish... But I am fine with the current (buggy?) implementation, too. I haven't run into any of its bugs yet. If someone doesn't like SyncFirst, he can press no to the syncfirst question. I can also see that if we want to make a bug-free syncfirst, the code becomes more and more complicated: 1. First of all syncfirst = gtk2 makes no sense (result: dangerous partial upgrade). We only need to syncfirst pacman. (In an optimal world, the new version of pacman would be automatically run to perform the requested operation to avoid partial upgrade. Unfortunately, even the pacman syntax can be changed in a major upgrade.) 2. I don't think that "third-party-package-manager needs pacman<=3.5.0" bug is a serious one (sync304.py). It can be fixed (reverse dependencies), or just simply ask users to put third-party-package-manager to SyncFirst, contradicting my comment in 1. But the more syncfirst packages, the more transaction interruption. (In this logic, pacman will first upgrade all the package managers installed to the system.) The conflict problem (sync303.py) is appears with --noconfirm only, right? 3. sync305.py is a tougher bug. Only reversedeps resolution, "fallback to original transaction" or a packager-trick could help here. Summary of my opinion: We can live without SyncFirst, the code would become simpler, but then we have to be careful with database/pacman upgrades. And imho the developer->users communication needs some modernization, too; maybe that is the simpler solution. NG ------------------------------------------------------ SZTE Klebelsberg Konyvtar - http://www.bibl.u-szeged.hu This message was sent using IMP: http://horde.org/imp/