Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Franklin PIAT
Hello,

Christian Perrier wrote a blog about dpkg triggers[1], titled "triggers:
those great improvements Joe User will never see". He pointed out that
it's a kind of great(*2) feature that will be unnoticed by end users.

That's true, IMHO. The funny (and *angering*) thing is, those users who
actually notice triggers are likely to complain :

 "Why the Hell do you run those triggers, it wastes my time !"

No matter if it actually save their time, since it's ran once for all
packages, rather than once per package. What users will notice it that
something is ran after the package *is installed* (from their POV), so
it can be perceived as a waste of time.

My point now : We should make sure they aren't right !

i.e We should be careful not to add lots of new triggers for doing new
stuffs, that eventually makes the installation to take longer. We can
still defer actions in the background by other means, like cron.

I've included some figures for man-db, as an example below (*3). (Thanks
to Colin Watson who maintain that other feature Joe User will never
notice).

Thanks to every one who worked on this trigger thing.
 
Franklin


----

[1] http://www.perrier.eu.org/weblog/2008/06/25#triggers
*2) Don't argue here, the discussion already occurred. I'm referring to
    the concept of delaying some actions, so it's only ran once for
    all installed package, in order to save time.
*3) Example of delayed triggers, man-db figures :

Foreword : I'm not blaming the maintainer, Colin Watson, as I can't make
my mind on whether it should have been enabled or not (plus see
Bug:#133917). Being able to opt-out would be great, but triggers don't
seem to allow that currently.

On Etch, /var/cache/man/index.db was not updated at installation, but
with a cron job. In Lenny, it will be triggered right after packages
installation :

etch:~# time dpkg -i /var/cache/apt/archives/manpages_2.39-1_all.deb
Selecting previously deselected package manpages.
(Reading database ... 53054 files and directories currently installed.)
Unpacking manpages (from .../manpages_2.39-1_all.deb) ...
Setting up manpages (2.39-1) ...

real 0m0.230s
user 0m0.080s
sys 0m0.040s

sid:~# time dpkg -i /var/cache/apt/archives/manpages_3.00-1_all.deb
Selecting previously deselected package manpages.
(Reading database ... 26933 files and directories currently installed.)
Unpacking manpages (from .../manpages_3.00-1_all.deb) ...
Setting up manpages (3.00-1) ...
Processing triggers for man-db ...

real 0m0.474s
user 0m0.104s
sys 0m0.152s

Now sid, with man-db triggers disabled :

sid:~# time dpkg -i /var/cache/apt/archives/manpages_3.00-1_all.deb
Selecting previously deselected package manpages.
(Reading database ... 26928 files and directories currently installed.)
Unpacking manpages (from .../manpages_3.00-1_all.deb) ...
Setting up manpages (3.00-1) ...

real 0m0.185s
user 0m0.052s
sys 0m0.036s



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Charles Plessy-12
Le Fri, Jun 27, 2008 at 10:31:54AM +0200, Franklin PIAT a écrit :
> The funny (and *angering*) thing is, those users who
> actually notice triggers are likely to complain :
>
>  "Why the Hell do you run those triggers, it wastes my time !"
 
 
> sid:~# time dpkg -i /var/cache/apt/archives/manpages_3.00-1_all.deb
> Selecting previously deselected package manpages.
> (Reading database ... 26933 files and directories currently installed.)
> Unpacking manpages (from .../manpages_3.00-1_all.deb) ...
> Setting up manpages (3.00-1) ...
> Processing triggers for man-db ...

Hi all,

Isn't the problem of these users that in the above output, the only
sentence that contains jargon is the one about the "triggers", and they
can not see why triggers are doing someghing good for them?. How to
understand the last sentence? Has man-db one or more triggers? Is
triggers a verb or a noun? What is the analogy between the triggers of
dpkg and those of databasees or firearms?

Maybe "Processing triggers" could be replaced by a 2-3 word summary of
what the trigger is really doing?

Have a nice day,

--
Charles Plessy
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Adam Borowski-3
On Sat, Jun 28, 2008 at 11:15:46AM +0900, Charles Plessy wrote:
> Le Fri, Jun 27, 2008 at 10:31:54AM +0200, Franklin PIAT a écrit :
> > The funny (and *angering*) thing is, those users who
> > actually notice triggers are likely to complain :
> >
> >  "Why the Hell do you run those triggers, it wastes my time !"

> Maybe "Processing triggers" could be replaced by a 2-3 word summary of
> what the trigger is really doing?

What about "Processing delayed configuration"?

--
1KB // Microsoft corollary to Hanlon's razor:
                // Never attribute to stupidity what can be
                // adequately explained by malice.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Ben Finney-2
Adam Borowski <[hidden email]> writes:

> On Sat, Jun 28, 2008 at 11:15:46AM +0900, Charles Plessy wrote:
> > Le Fri, Jun 27, 2008 at 10:31:54AM +0200, Franklin PIAT a écrit :
> > > The funny (and *angering*) thing is, those users who
> > > actually notice triggers are likely to complain :
> > >
> > >  "Why the Hell do you run those triggers, it wastes my time !"
>
> > Maybe "Processing triggers" could be replaced by a 2-3 word
> > summary of what the trigger is really doing?
>
> What about "Processing delayed configuration"?

Good idea, but perhaps "delayed" carries too negative a connotation
(in English). Better might be "deferred" or "pending".

How about "Resuming deferred installation steps" or similar?

--
 \       “What I resent is that the range of your vision should be the |
  `\                                 limit of my action.” —Henry James |
_o__)                                                                  |
Ben Finney


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Christian Perrier
In reply to this post by Franklin PIAT
Quoting Franklin PIAT ([hidden email]):

> That's true, IMHO. The funny (and *angering*) thing is, those users who
> actually notice triggers are likely to complain :
>
>  "Why the Hell do you run those triggers, it wastes my time !"

Are you basing this assumption on somethign really experienced?

Indeed, when I run an "apt<whatever> dist-upgrade", I just launch the
command, look at the list of actions that are planned, hit "Y" to
confirm and just switch to another window and come back some hours
later.

In short, I don't really care to read what's happening or displayed on
my screen..:-)

Do you think that real users will worry about mysterious actions
happening after package installs? After all, it's quite some time
since we've see people complaining about actions happening after every
package install....

I understand the point in your suggestion and we certainly should be
careful about potential triggers abuse (just like debconf abuse I'm
hunting here and there) but I don't really think that the complaints
will come from our users.


signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Franklin PIAT


On Sat, June 28, 2008 15:12, Christian Perrier wrote:
> Quoting Franklin PIAT ([hidden email]):
>
>> That's true, IMHO. The funny (and *angering*) thing is, those users who
>> actually notice triggers are likely to complain :
>>
>>  "Why the Hell do you run those triggers, it wastes my time !"
>
> Are you basing this assumption on somethign really experienced?

I'll answer your third point first : Yes, I wish we avoid potential
triggers abuses, even if it's for good will .

I'm not just afraid of what people complains about. I am also afraid of
those hundreds of little things that can potentially get people pissed
off.

> Indeed, when I run an "apt<whatever> dist-upgrade", I just launch the
> command, look at the list of actions that are planned, hit "Y" to
> confirm and just switch to another window and come back some hours
> later.

When I run "apt-get install foo", I want it to be damed fast, since I need
to continue my work.

[..]
> I understand the point in your suggestion and we certainly should be
> careful about potential triggers abuse (just like debconf abuse I'm
> hunting here and there) but I don't really think that the complaints
> will come from our users.

Franklin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Raphael Geissert
Franklin PIAT wrote:
> On Sat, June 28, 2008 15:12, Christian Perrier wrote:
>> Indeed, when I run an "apt<whatever> dist-upgrade", I just launch the
>> command, look at the list of actions that are planned, hit "Y" to
>> confirm and just switch to another window and come back some hours
>> later.
>
> When I run "apt-get install foo", I want it to be damed fast, since I need
> to continue my work.

But wasn't the cronjob actually a resources waster regenerating the database
even when not needed? (note that I don't really know how the cronjob used
to work, I'm guessing here).

Cheers,
Raphael



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Bernhard R. Link-2
In reply to this post by Franklin PIAT
* Franklin PIAT <[hidden email]> [080628 23:12]:
> > Indeed, when I run an "apt<whatever> dist-upgrade", I just launch the
> > command, look at the list of actions that are planned, hit "Y" to
> > confirm and just switch to another window and come back some hours
> > later.
>
> When I run "apt-get install foo", I want it to be damed fast, since I need
> to continue my work.

I think this is a very important usability factor.

Please note that there are not only experiened users that have
confidence in their understanding of the system and the system itself
but also people not having that background.

Fiddling with package management is usually quite a critical point: You
often do not do what exactly it does, so reverting it manually will not
be possible. Thus if you lack confidence, installing or removing
packages means quite some stress, and the earlier it is finished the
earlier you leave that unhealthy state.

At least that is my experience when using other systems like Yast on
SuSe: There are some interfaces I do not fully understand, it does some
things related to what I asked it, and then is writes several minutes
(at least it feels like that) with doing things that seem totally
unrelated (I guess it just rewrites some config and has suboptimal
triggers when to write what).

I guess unexperienced people might feel the same when seeing this
triggers. (Even I are sometimes at loss why it does specific things,
for example updating mandb after I try to install a package but that
failed).

Hochachtungsvoll,
        Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
        Niklaus Wirth


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Andreas Tille
In reply to this post by Christian Perrier
On Sat, 28 Jun 2008, Christian Perrier wrote:

> Are you basing this assumption on somethign really experienced?

It is even documented on debian-devel:

     http://lists.debian.org/debian-devel/2008/06/msg00117.html

> Indeed, when I run an "apt<whatever> dist-upgrade", I just launch the
> command, look at the list of actions that are planned, hit "Y" to
> confirm and just switch to another window and come back some hours
> later.

Well, I have more than one window on my desktop and sometimes look at
the process that continuosely spits out lines I never realised before ...

> In short, I don't really care to read what's happening or displayed on
> my screen..:-)

I'd regard this as a grand fathers phenomenon: Beeing unable to
concentrate on more than one thing. ;-))))

> Do you think that real users will worry about mysterious actions
> happening after package installs?

Honestly, I think so.  Especially new users who are not yet comfortable
with the fact that in Debian most things went very smoothly and you
do not need to observe continuosely.

Kind regards

           Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Charles Plessy-12
In reply to this post by Adam Borowski-3
>> Maybe "Processing triggers" could be replaced by a 2-3 word summary of
>> what the trigger is really doing?

> What about "Processing delayed configuration"?

Well, I was originally thinking about someting specific for each
trigger, but your proposition is probably sufficient and simpler to
implement.

Have a nice day,

--
Charles


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Christian Perrier
Quoting Charles Plessy ([hidden email]):
> >> Maybe "Processing triggers" could be replaced by a 2-3 word summary of
> >> what the trigger is really doing?
>
> > What about "Processing delayed configuration"?
>
> Well, I was originally thinking about someting specific for each
> trigger, but your proposition is probably sufficient and simpler to
> implement.

We had the same problem when translating to French.

A "trigger" is indeed pretty tricky to translate. The English word
gives a good feeling of "something that sets an action to be processed
later" so we settled on the french verb "déclencher" and we're using
"déclenchements" (quite word-for-word translation).

But I indeed feel that few users have a good idea of what this might
be and the same probably stands for "triggers" in English (with the
extra fact that many users of English strings for dpkg are actually
non native speakers).

I like "Processing delayed configuration". This is probably slightly
less precise but really clear of what this thing "Joe User will never
know about" is.

We could use "delayed configuration" instead of "triggers" in messages
meant to be displayed to users while we could keep "triggers" in
internal messages.

Before I mention this in the dpkg development list, are there any
other comments about that wording ?



signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Neil Williams-4
On Mon, 2008-06-30 at 07:42 +0200, Christian Perrier wrote:
> Quoting Charles Plessy ([hidden email]):
> > >> Maybe "Processing triggers" could be replaced by a 2-3 word summary of
> > >> what the trigger is really doing?
> >
> > > What about "Processing delayed configuration"?

s/delayed/deferred/ ?

or maybe 'postponed' ?

"To defer is to decide to do something later on: to defer making a
payment. To delay is sometimes equivalent to defer, but usually it is to
act in a dilatory manner and thus lay something aside: to delay one's
departure. To postpone a thing is to put it off to (usually) some
particular time in the future, with the intention of beginning or
resuming it then: to postpone an election."

Of all of those, postponed could be closest: a trigger action is
rescheduled with the definite intention of beginning at that time.

To get across the idea that "the action is postponed in order that
similar actions are run together to reduce overall time":

"Processing groups of actions postponed during the initial setup"

or

"Processing groups of similar actions postponed during the initial
setup"

> I like "Processing delayed configuration". This is probably slightly
> less precise but really clear of what this thing "Joe User will never
> know about" is.

delayed from when? I think it is better to extend the message and be
more verbose. I also think that some indication of *why* things were
delayed would solve the problem.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Thibaut Paumard-3
In reply to this post by Charles Plessy-12

Le 28 juin 08 à 04:15, Charles Plessy a écrit :

> Le Fri, Jun 27, 2008 at 10:31:54AM +0200, Franklin PIAT a écrit :
>> sid:~# time dpkg -i /var/cache/apt/archives/manpages_3.00-1_all.deb
>> Selecting previously deselected package manpages.
>> (Reading database ... 26933 files and directories currently  
>> installed.)
>> Unpacking manpages (from .../manpages_3.00-1_all.deb) ...
>> Setting up manpages (3.00-1) ...
>> Processing triggers for man-db ...
>
> [...]
>
> Maybe "Processing triggers" could be replaced by a 2-3 word summary of
> what the trigger is really doing?
>

I don't know what the best practice is, but in "my" trigger action  
(update-yorickdoc), I print one sentence, that would come right after  
the "Processing triggers for yorick-doc" line:

Building yorick documentation in ....

So the user knows exactly what happens.

In addition, there is an option in a conffile to deactivate this  
automatic re-building (in /etc/yorick-doc). If automatic rebuilding  
is opted-out, you still get the "Processing triggers" message, and  
one line saying that nothing will be done. So you just loose a very  
short time while a no-op is being triggered.

Best regards, Thibaut.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Bernd Eckenfels
In reply to this post by Neil Williams-4
In article <[hidden email]> you wrote:
> delayed from when? I think it is better to extend the message and be
> more verbose. I also think that some indication of *why* things were
> delayed would solve the problem.

I must admit i dont know how those triggers work, but I asume it is

"Remebering to process xxx once at end of installation"?

(In that way defering is better than postponing)

However the question is, if the message is only telling us, that it is not
doing anything, why not just skipping it?

Gruss
Bernd


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Thibaut Paumard-3

Le 30 juin 08 à 11:56, Bernd Eckenfels a écrit :

> In article <[hidden email]> you wrote:
>> delayed from when? I think it is better to extend the message and be
>> more verbose. I also think that some indication of *why* things were
>> delayed would solve the problem.
>
> I must admit i dont know how those triggers work, but I asume it is
>
> "Remebering to process xxx once at end of installation"?
>
> (In that way defering is better than postponing)
>
> However the question is, if the message is only telling us, that it  
> is not
> doing anything, why not just skipping it?

No, it tells us that it is doing stuff _now_, that has been scheduled  
earlier. Since those tasks may take a long time (that's why we want  
to run them only once for several packages), you definitely need a  
message, but it would be nice if this message could be customized by  
the package or point perhaps to some documentation about these triggers.

Regards, T.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Scott Kitterman-5
In reply to this post by Christian Perrier
On Monday 30 June 2008 01:42, Christian Perrier wrote:

> Quoting Charles Plessy ([hidden email]):
> > >> Maybe "Processing triggers" could be replaced by a 2-3 word summary of
> > >> what the trigger is really doing?
> > >
> > > What about "Processing delayed configuration"?
> >
> > Well, I was originally thinking about someting specific for each
> > trigger, but your proposition is probably sufficient and simpler to
> > implement.
>
> We had the same problem when translating to French.
>
> A "trigger" is indeed pretty tricky to translate. The English word
> gives a good feeling of "something that sets an action to be processed
> later" so we settled on the french verb "déclencher" and we're using
> "déclenchements" (quite word-for-word translation).
>
> But I indeed feel that few users have a good idea of what this might
> be and the same probably stands for "triggers" in English (with the
> extra fact that many users of English strings for dpkg are actually
> non native speakers).
>
> I like "Processing delayed configuration". This is probably slightly
> less precise but really clear of what this thing "Joe User will never
> know about" is.
>
> We could use "delayed configuration" instead of "triggers" in messages
> meant to be displayed to users while we could keep "triggers" in
> internal messages.
>
> Before I mention this in the dpkg development list, are there any
> other comments about that wording ?

From a "Joe User" perspective, I think delay rather misses the point.  The
reason for triggers is not to do stuff later, it's to consolidate processing
so actions don't need to be done multiple times.  Delay is the mechanism
chosen for doing this.

I think it you substitute delayed with consolidated it, at least in English,
is accurate and carries the correct connotation that a user would more likely
understand.

Scott K


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Tilo Schwarz
On Mon, 30 Jun 2008 15:27:55 +0200, Scott Kitterman <[hidden email]>  
wrote:

[...]

> From a "Joe User" perspective, I think delay rather misses the point.  
> The
> reason for triggers is not to do stuff later, it's to consolidate  
> processing
> so actions don't need to be done multiple times.

Actually, as "Joe User" (me ;-) I'm wondering, why I get during an update  
of let's say 20 packages the triggers message for man-db and menu not once  
at the end, but several times every few packages. I thought, the idea is,  
to let the triggers to the work once during one install.

Regards,

     Tilo


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Joey Hess
Tilo Schwarz wrote:
> Actually, as "Joe User" (me ;-) I'm wondering, why I get during an update
> of let's say 20 packages the triggers message for man-db and menu not
> once at the end, but several times every few packages. I thought, the
> idea is, to let the triggers to the work once during one install.

#473461

--
see shy jo

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Andreas Tille
On Wed, 2 Jul 2008, Joey Hess wrote:

> #473461

But this bug ends with a question:

     What do you think?

/me as a completely uneducated apt / aptitude user thinks: Triggers have
done more harm than good.  Please consider this as a stupid users opinion
but I would not mention this "feature" as a thrilling enhancement in the
release notes of Lenny (at least if until then are no effective means done
to prevent running triggers so frequently = #473461 is fixed).  In other
words in my eyes #473461 should not be wishlist but grave.

Kind regards

          Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.

Lars Wirzenius-5
to, 2008-07-03 kello 08:24 +0200, Andreas Tille kirjoitti:
> /me as a completely uneducated apt / aptitude user thinks: Triggers have
> done more harm than good.

I haven't been following trigger adoption very much, so I'm ignorant:
what harm have triggers done?



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

12