Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   ArchLinux Pacman Development (http://www.linux-archive.org/archlinux-pacman-development/)
-   -   Hooks in pacman (http://www.linux-archive.org/archlinux-pacman-development/483185-hooks-pacman.html)

Daniel Mendler 01-30-2011 10:23 PM

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

Sascha Kruse 01-30-2011 11:50 PM

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

Daniel Mendler 01-31-2011 12:07 AM

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

Sascha Kruse 01-31-2011 02:06 AM

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

"Marc - A. Dahlhaus" 01-31-2011 09:45 AM

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

Dan McGee 02-01-2011 01:29 AM

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


All times are GMT. The time now is 07:16 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.