Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.
Andreas Tille dijo [Thu, Jul 03, 2008 at 09:24:32AM +0200]:
> >I haven't been following trigger adoption very much, so I'm ignorant:
> >what harm have triggers done?
> It slows down apt-get / aptitude by calling update-menus / update-mandb
> for every package that drops a file into this directory. I have not done
> measures whether the installation time with and without triggers is
> really different (perhaps there are some other means of optimisation
> done) but the user reads much more lines about things that are done when
> calling apt which is annoing and leaves open questions for the user.
> This is bad.
Well, calling them once after every package modified its bits, instead
of each of them calling them without explicitly notifying you. So,
it's perceived as a longer time, but you didn't measure all the time
saved by _not_ calling it.
> I reported another problem at
> which was in principle easy to circumvent, but I did not got an
> answer to my later question in this thread
> where I wanted to know whether there is some means to obtain a
> return code of update-menus about the reasons of the failure. So
> my script has no chance to differentiate between a real problem in
> the installation (really missing config file) or a problem that
> was caused by an (IMHO unnecessary and boring) call because of
> the trigger feature.
This, however, is an interesting point to work on - Of course, it
should be fixed by making more robust the processes that are
triggered, not by removing a feature by labelling it as a bug!
Gunnar Wolf - email@example.com - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF