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


 
 
LinkBack Thread Tools
 
Old 01-30-2011, 10:23 PM
Daniel Mendler
 
Default Hooks in pacman

Hi,

I added simple hooks support to pacman yesterday. Unfortunately I have
not seen before that Sascha Kruse is already working on it. My concept
is simpler and similar to the scriptlets. You might want to take a look
at it even though.

And another topic: I have seen that Allan is working on gpg-support. How
far is this from deployment?

Daniel
 
Old 01-30-2011, 11:50 PM
Sascha Kruse
 
Default Hooks in pacman

2011/1/31 Daniel Mendler <mail@daniel-mendler.de>:
> Hi,
>
> I added simple hooks support to pacman yesterday. Unfortunately I have
> not seen before that Sascha Kruse is already working on it. My concept
> is simpler and similar to the scriptlets. You might want to take a look
> at it even though.

My work up to this point was pretty much useless anyway. So I'll
abandon my work for now and wait how this evolves.

Greetings,
Sascha
 
Old 01-31-2011, 12:07 AM
Daniel Mendler
 
Default Hooks in pacman

Hi

>> I added simple hooks support to pacman yesterday. Unfortunately I have
>> not seen before that Sascha Kruse is already working on it. My concept
>> is simpler and similar to the scriptlets. You might want to take a look
>> at it even though.
>
> My work up to this point was pretty much useless anyway. So I'll
> abandon my work for now and wait how this evolves.

It wasn't my intentions to stop your efforts here. I just didn't want to
throw away my patches, so I sent them here. Because we both want hooks
we should combine our work The problem is that the patches are a bit
different. So at first we should discuss how hooks should look like.

I like the concept with the shell-functions used in the
install-scriptlets, so I used this scheme. Furthermore I think the hooks
should be simple, this means only on a per-package (implemented in my
patch) and per-transaction base. All other cases can be handled on the
script-level (filtering for files, package names, etc). Activating a
patch is as simple as copying a file to /etc/pacman.d/hooks.

The per-transaction hooks are not yet in my patch, but this is easy to
add (just add runhooks calls). The nice thing is that the
per-transaction-hooks can replace the manual ldconfig runs for example.

I am very interested in opinions of the development team!

Daniel
 
Old 01-31-2011, 02:06 AM
Sascha Kruse
 
Default Hooks in pacman

2011/1/31 Daniel Mendler <mail@daniel-mendler.de>:
> Hi
>
>>> I added simple hooks support to pacman yesterday. Unfortunately I have
>>> not seen before that Sascha Kruse is already working on it. My concept
>>> is simpler and similar to the scriptlets. You might want to take a look
>>> at it even though.
>>
>> My work up to this point was pretty much useless anyway. So I'll
>> abandon my work for now and wait how this evolves.
>
> It wasn't my intentions to stop your efforts here. I just didn't want to
> throw away my patches, so I sent them here. Because we both want hooks
> we should combine our work The problem is that the patches are a bit
> different. So at first we should discuss how hooks should look like.

Yes, of course. I just tried to say that your patches look far more promising
than the one I did. If there's something i can help with,i will.

> I like the concept with the shell-functions used in the
> install-scriptlets, so I used this scheme. Furthermore I think the hooks
> should be simple, this means only on a per-package (implemented in my
> patch) and per-transaction base. All other cases can be handled on the
> script-level (filtering for files, package names, etc). Activating a
> patch is as simple as copying a file to /etc/pacman.d/hooks.

I agree with the shellfunctions.
But I'm not sure wether the filtering for packages and files should be
done within these scripts. The pro I see in putting this logic into
the scripts is that there's no need for a configuration file for the hooks
(given that we differentiate between transaction-based and package-based
hooks by a prefix/suffix in their name or something similar).

But on the other hand are the majority of usescases for hooks that
come to my mind either depending on a certain package or file.
Things like updating the font-cache or do custom stuff after a kernel
upgrade.


> I am very interested in opinions of the development team!
> Me too.

greetings,
Sascha
 
Old 01-31-2011, 09:45 AM
"Marc - A. Dahlhaus"
 
Default Hooks in pacman

Am Montag, den 31.01.2011, 02:07 +0100 schrieb Daniel Mendler:
> Hi

Hello,

> >> I added simple hooks support to pacman yesterday. Unfortunately I have
> >> not seen before that Sascha Kruse is already working on it. My concept
> >> is simpler and similar to the scriptlets. You might want to take a look
> >> at it even though.
> >
> > My work up to this point was pretty much useless anyway. So I'll
> > abandon my work for now and wait how this evolves.
>
> It wasn't my intentions to stop your efforts here. I just didn't want to
> throw away my patches, so I sent them here. Because we both want hooks
> we should combine our work The problem is that the patches are a bit
> different. So at first we should discuss how hooks should look like.
>
> I like the concept with the shell-functions used in the
> install-scriptlets, so I used this scheme. Furthermore I think the hooks
> should be simple, this means only on a per-package (implemented in my
> patch) and per-transaction base. All other cases can be handled on the
> script-level (filtering for files, package names, etc). Activating a
> patch is as simple as copying a file to /etc/pacman.d/hooks.

Did it mostly about the same way:

I added a /usr/share/pacman/hook.d dir and installed hook scripts there.

I added some helper functions to a /usr/share/pacman/hook.sh and sourced
that file to the environment of the install scriptlets. I think i'll
change this to simple "run-hook scriptname" and "trans-hook scriptname"
bash scripts, because the including is not needed...

I also added a /var/lib/packman/hook dir and touched empty files in
there, that have the same name as the hook script to run for transaction
hooks and a call to "/usr/share/pacman/hook.sh transaction" was added
to /lib/libalpm/util.c after the callout to ldconfig which does a simple
walk over the touched empty files in the /var/lib/packman/hook dir which
fires up the corresponding hook and removes the empty file after that.

It's based on pacman 3.3 and i have a forward port to 3.4 already on my
agenda, if someone cares i can share the patches after that.

IIRC there was a solution to run hooks on the basis of installed files
(names or pathes) wanted / proposed last time we discussed triggers /
hooks for pacman here. I'll try to dig up the thread in the archive...

> The per-transaction hooks are not yet in my patch, but this is easy to
> add (just add runhooks calls). The nice thing is that the
> per-transaction-hooks can replace the manual ldconfig runs for example.
>
> I am very interested in opinions of the development team!
>
> Daniel


Marc
 
Old 02-01-2011, 01:29 AM
Dan McGee
 
Default Hooks in pacman

On Mon, Jan 31, 2011 at 4:45 AM, Marc - A. Dahlhaus <mad@wol.de> wrote:
> Am Montag, den 31.01.2011, 02:07 +0100 schrieb Daniel Mendler:
>> Hi
>
> Hello,
>
>> >> I added simple hooks support to pacman yesterday. Unfortunately I have
>> >> not seen before that Sascha Kruse is already working on it. My concept
>> >> is simpler and similar to the scriptlets. You might want to take a look
>> >> at it even though.
>> >
>> > My work up to this point was pretty much useless anyway. So I'll
>> > abandon my work for now and wait how this evolves.
>>
>> It wasn't my intentions to stop your efforts here. I just didn't want to
>> throw away my patches, so I sent them here. Because we both want hooks
>> we should combine our work The problem is that the patches are a bit
>> different. So at first we should discuss how hooks should look like.
>>
>> I like the concept with the shell-functions used in the
>> install-scriptlets, so I used this scheme. Furthermore I think the hooks
>> should be simple, this means only on a per-package (implemented in my
>> patch) and per-transaction base. All other cases can be handled on the
>> script-level (filtering for files, package names, etc). Activating a
>> patch is as simple as copying a file to /etc/pacman.d/hooks.
>
> Did it mostly about the same way:
>
> I added a /usr/share/pacman/hook.d dir and installed hook scripts there.
>
> I added some helper functions to a /usr/share/pacman/hook.sh and sourced
> that file to the environment of the install scriptlets. I think i'll
> change this to simple "run-hook scriptname" and "trans-hook scriptname"
> bash scripts, because the including is not needed...
>
> I also added a /var/lib/packman/hook dir and touched empty files in
> there, that have the same name as the hook script to run for transaction
> hooks and a call to "/usr/share/pacman/hook.sh transaction" was added
> to /lib/libalpm/util.c after the callout to ldconfig which does a simple
> walk over the touched empty files in the /var/lib/packman/hook dir which
> fires up the corresponding hook and removes the empty file after that.
>
> It's based on pacman 3.3 and i have a forward port to 3.4 already on my
> agenda, if someone cares i can share the patches after that.
>
> IIRC there was a solution to run hooks on the basis of installed files
> (names or pathes) wanted / proposed last time we discussed triggers /
> hooks for pacman here. I'll try to dig up the thread in the archive...
>
>> The per-transaction hooks are not yet in my patch, but this is easy to
>> add (just add runhooks calls). The nice thing is that the
>> per-transaction-hooks can replace the manual ldconfig runs for example.
>>
>> I am very interested in opinions of the development team!

So seems like many people have been hacking in private on this one. It
is good that people are interested, bad that it is coming up now. We
need to get a 3.5 out the door and right now my time is better spent
looking at issues related to and getting ready for a release of that.

These patches/work items will get a look in good time, but for now,
they are simmering and waiting for 3.6.X development to start (updated
today): https://wiki.archlinux.org/index.php/Pacman_Roadmap

-Dan
 

Thread Tools




All times are GMT. The time now is 08:25 AM.

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