[pacman-dev] [PATCH] Remove SyncFirst option

[Nagy Gabor]

> This has outlived its usefulness and causes more problems than it
> solves.
>
> Signed-off-by: Dan McGee <dan at 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/