[pacman-dev] [PATCH] Remove SyncFirst option
ngaba at bibl.u-szeged.hu
Thu Feb 16 16:31:28 EST 2012
> This has outlived its usefulness and causes more problems than it
> Signed-off-by: Dan McGee <dan at archlinux.org>
> This is an RFC first of all, so please feel free to comment.
> 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.
> 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.
SZTE Klebelsberg Konyvtar - http://www.bibl.u-szeged.hu
This message was sent using IMP: http://horde.org/imp/
More information about the pacman-dev