FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-07-2011, 08:09 PM
David Kalnischkies
 
Default Bash-completion with triggers

On Thu, Apr 7, 2011 at 21:19, David Paleino <dapal@debian.org> wrote:
> On Thu, 7 Apr 2011 22:14:31 +0300, Eugene V. Lyubimkin wrote:
>
>> On 2011-04-07 18:15, Goswin von Brederlow wrote:
>> > Dpkg::Post-Invoke would be the right (best available) one. That would
>> > call your trigger after every dpkg invocation [...]
>>
>> This is not true, 'Dpkg::*-Invoke' script chain are called once
>> before/after all dpkg invocations.
>
> So it's just like a trigger monitoring /? (without the implications of triggers
> in terms of sequence of operations)

JFTR:
1. All scripts configured in DPKG::Pre-Invoke are called
2. All scripts configured in DPKG-Pre-Install-Pkgs are called
(and they get the information which packages will be installed).
3. APT does all the crazy stuff it does with dpkg
4. All scripts configured in DPKG::Post-Invoke are called

So in a way Post-Invoke could really be seen as a trigger on /.
And its not before/after every dpkg invocation, but before the first
and after the last dpkg invocation (as APT calls dpkg multiple times).


> This is meaningless to me. This way, my postinst would be run at *every* package
> installation, not only those installing files in /usr/bin/ and companions.

Most real world operations include at least one package with a binary in
these locations. After all, i am installing or upgrading an application and
all its dependencies are just there because they are needed for it…

As all applications ship a manpage (lets dream that all are lintian clean)
we would have two triggers called again and again and properly multiple
times in a single APT operation…


If you would use the APT hooks users of plain dpkg would be out of luck.
Same for people with very obscure packagemanagers (e.g. smart),
but after all its completion and not something mission critical -
even if i can't live without completion myself - so its properly okay to
ignore these cases as people who really use it on a regular basis
will properly know how to set something up on their own.


If you want to, you can properly get along with searching for
accessed/modified files in those directories to get the knowledge
if something was changed and if yes you know even what.


Best regards

David Kalnischkies


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/BANLkTi JbkJ~m3-L5Yd1WFzJkEdu3Q@mail.gmail.com
 
Old 04-08-2011, 02:25 PM
Goswin von Brederlow
 
Default Bash-completion with triggers

"Eugene V. Lyubimkin" <jackyf@debian.org> writes:

> On 2011-04-07 18:15, Goswin von Brederlow wrote:
>> Dpkg::Post-Invoke would be the right (best available) one. That would
>> call your trigger after every dpkg invocation [...]
>
> This is not true, 'Dpkg::*-Invoke' script chain are called once
> before/after all dpkg invocations.
>
>> But those hooks would only wotk for apt/aptitude. Not for [...] cupt
>
> This is not true as well.

I stand corrected then. cupt rules.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87vcyolt0m.fsf@frosties.localnet">http://lists.debian.org/87vcyolt0m.fsf@frosties.localnet
 
Old 04-10-2011, 09:56 AM
David Paleino
 
Default Bash-completion with triggers

A quick update...

On Thu, 7 Apr 2011 15:16:20 +0200, Raphael Hertzog wrote:

> The trigger is going to happen very often (like the man-db one) and
> with a 10s impact it's very noticable...

I think the time spent was the major objection, so I stripped it down to...

$ time ./update-bash-completion
bash-completion: updating completion symlinks... done.

real 0m0.225s
user 0m0.148s
sys 0m0.020s
$

Now, with that time spent, I suppose the objections against triggers would be
fewer and less important. Am I wrong?
I must say I'm a bit uncomfortable with APT-hooks, since the update script
would then be run even for packages with no executable at all (lib*, python-*,
and so on). So, I still prefer a file-trigger.

However, if I get objections again, I will just use hooks, and do what the
community prefers

Kindly,
David

--
. '`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://deb.li/dapal
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
 
Old 04-10-2011, 10:11 AM
"Eugene V. Lyubimkin"
 
Default Bash-completion with triggers

On 2011-04-10 11:56, David Paleino wrote:
> I think the time spent was the major objection, so I stripped it down to...
>
> $ time ./update-bash-completion
> bash-completion: updating completion symlinks... done.
>
> real 0m0.225s
> user 0m0.148s
> sys 0m0.020s
> $

Very good!

> Now, with that time spent, I suppose the objections against triggers would be
> fewer and less important. Am I wrong?
> I must say I'm a bit uncomfortable with APT-hooks, since the update script
> would then be run even for packages with no executable at all (lib*, python-*,
> and so on). So, I still prefer a file-trigger.

Sure, using APT hooks is a hack (like Goswin said already). From the
time output above, I see it's now much faster than the man-db trigger? If
so, I would say go ahead with file triggers.

--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110410101137.GA21569@r500-debian">http://lists.debian.org/20110410101137.GA21569@r500-debian
 
Old 04-10-2011, 10:19 AM
David Paleino
 
Default Bash-completion with triggers

On Sun, 10 Apr 2011 13:11:57 +0300, Eugene V. Lyubimkin wrote:

> On 2011-04-10 11:56, David Paleino wrote:
> > Now, with that time spent, I suppose the objections against triggers would
> > be fewer and less important. Am I wrong?
> > I must say I'm a bit uncomfortable with APT-hooks, since the update script
> > would then be run even for packages with no executable at all (lib*,
> > python-*, and so on). So, I still prefer a file-trigger.
>
> Sure, using APT hooks is a hack (like Goswin said already). From the
> time output above, I see it's now much faster than the man-db trigger? If
> so, I would say go ahead with file triggers.

Seems so. I still need to test it thoroughly, but I'm confident the time spent
won't vary too much.

David

--
. '`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://deb.li/dapal
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
 
Old 04-10-2011, 10:24 AM
Ansgar Burchardt
 
Default Bash-completion with triggers

Hi,

David Paleino <dapal@debian.org> writes:
> I've implemented a new revision of bash-completion, which uses debtriggers(5)
> to load only relevant completions, and symlink them when something
> touches /usr/bin/, /usr/games/, /usr/sbin/, /sbin/, /bin/, and so on.

zsh supports autoloading of functions: the time it is called first, zsh
will look for its definition in several directories (see "autoloading
functions" in zshmisc(1)). As far as I know this is used by the
completion function to avoid loading unneeded parts.

Would it be possible for bash to use a similar scheme instead of using
triggers? That way completions would also be available for software
installed into /usr/local (not using dpkg) without having to run some
command.

Regards,
Ansgar


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87tye61k1g.fsf@marvin.43-1.org">http://lists.debian.org/87tye61k1g.fsf@marvin.43-1.org
 
Old 04-10-2011, 10:54 AM
David Paleino
 
Default Bash-completion with triggers

On Sun, 10 Apr 2011 12:24:11 +0200, Ansgar Burchardt wrote:

> David Paleino <dapal@debian.org> writes:
> > I've implemented a new revision of bash-completion, which uses
> > debtriggers(5) to load only relevant completions, and symlink them when
> > something touches /usr/bin/, /usr/games/, /usr/sbin/, /sbin/, /bin/, and so
> > on.
>
> zsh supports autoloading of functions: the time it is called first, zsh
> will look for its definition in several directories (see "autoloading
> functions" in zshmisc(1)). As far as I know this is used by the
> completion function to avoid loading unneeded parts.
>
> Would it be possible for bash to use a similar scheme instead of using
> triggers? That way completions would also be available for software
> installed into /usr/local (not using dpkg) without having to run some
> command.

<spoiler>
Yes, but we planned that upstream for 2.x or even later, since it involves
some rewriting of bash-completion itself.

Also, we're currently targetting bash >= 3.2, so we need to take care of
backwards compatibility.
For 2.0, we're probably bumping that requirement to >= 4.1, so we can use newer
bash features, which will hopefully make things faster.
</spoiler>

Kindly,
David

--
. '`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://deb.li/dapal
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
 
Old 04-10-2011, 12:55 PM
Josselin Mouette
 
Default Bash-completion with triggers

Le dimanche 10 avril 2011 * 12:54 +0200, David Paleino a écrit :
> Also, we're currently targetting bash >= 3.2, so we need to take care of
> backwards compatibility.
> For 2.0, we're probably bumping that requirement to >= 4.1, so we can use newer
> bash features, which will hopefully make things faster.

With bash 4.1 in squeeze, what’s the point of waiting?

--
.'`. Josselin Mouette
: :' :
`. `' “If you behave this way because you are blackmailed by someone,
`- […] I will see what I can do for you.” -- Jörg Schilling
 
Old 04-10-2011, 01:25 PM
David Paleino
 
Default Bash-completion with triggers

On Sun, 10 Apr 2011 14:55:12 +0200, Josselin Mouette wrote:

> Le dimanche 10 avril 2011 * 12:54 +0200, David Paleino a écrit :
> > Also, we're currently targetting bash >= 3.2, so we need to take care of
> > backwards compatibility.
> > For 2.0, we're probably bumping that requirement to >= 4.1, so we can use
> > newer bash features, which will hopefully make things faster.
>
> With bash 4.1 in squeeze, what’s the point of waiting?

Debian != world, and since I'm upstream too...

--
. '`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://deb.li/dapal
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
 
Old 04-10-2011, 01:29 PM
David Paleino
 
Default Bash-completion with triggers

On Sun, 10 Apr 2011 15:25:09 +0200, David Paleino wrote:

> On Sun, 10 Apr 2011 14:55:12 +0200, Josselin Mouette wrote:
>
> > Le dimanche 10 avril 2011 * 12:54 +0200, David Paleino a écrit :
> > > Also, we're currently targetting bash >= 3.2, so we need to take care of
> > > backwards compatibility.
> > > For 2.0, we're probably bumping that requirement to >= 4.1, so we can use
> > > newer bash features, which will hopefully make things faster.
> >
> > With bash 4.1 in squeeze, what’s the point of waiting?
>
> Debian != world, and since I'm upstream too...

(It's even true that, as someone said on the upstream ML, "when Debian stable
has X, everyone else has X+1"...)

--
. '`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://deb.li/dapal
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
 

Thread Tools




All times are GMT. The time now is 01:32 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org