alpm-hooks: OVERRIDING HOOKS

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

alpm-hooks: OVERRIDING HOOKS

Sean Enck
If you read the "man alpm-hooks" it alludes to a priority-based directory
overriding behavior. But the directory/priority queue for when hooks are
loaded isn't stated [0]

Some quick searching indicates: "/etc/pacman.d/hooks" [1] is (at least one
example) place that will override "/usr/share/libalpm/hooks".

The directories/priorities should be enumerated in the docs. Even if this
is enumerated in another doc page somewhere, since the behavior really
_matters_ in alpm-hooks it should probably be at least re-enumerated here
if not become the source-of-record for this information.

--Sean

[0] https://www.archlinux.org/pacman/alpm-hooks.5.html
[1] https://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks
Reply | Threaded
Open this post in threaded view
|

Re: alpm-hooks: OVERRIDING HOOKS

Andrew Gregory
On 03/17/18 at 10:36pm, Sean Enck wrote:

> If you read the "man alpm-hooks" it alludes to a priority-based directory
> overriding behavior. But the directory/priority queue for when hooks are
> loaded isn't stated [0]
>
> Some quick searching indicates: "/etc/pacman.d/hooks" [1] is (at least one
> example) place that will override "/usr/share/libalpm/hooks".
>
> The directories/priorities should be enumerated in the docs. Even if this
> is enumerated in another doc page somewhere, since the behavior really
> _matters_ in alpm-hooks it should probably be at least re-enumerated here
> if not become the source-of-record for this information.
>
> --Sean
>
> [0] https://www.archlinux.org/pacman/alpm-hooks.5.html
> [1] https://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks

man pacman.conf
Reply | Threaded
Open this post in threaded view
|

Re: alpm-hooks: OVERRIDING HOOKS

Sean Enck
I figured that it was spelled out somewhere...it is more that whatever that
one-way doc pattern was going to be (pacman.conf -> alpm-hooks) makes the
context for understanding the "OVERRIDING HOOKS" section tougher to consume
from alpm-hooks (e.g. there is no "See Also: pacman.conf").

On Sat, Mar 17, 2018 at 6:43 PM, Andrew Gregory <[hidden email]>
wrote:

> On 03/17/18 at 10:36pm, Sean Enck wrote:
> > If you read the "man alpm-hooks" it alludes to a priority-based directory
> > overriding behavior. But the directory/priority queue for when hooks are
> > loaded isn't stated [0]
> >
> > Some quick searching indicates: "/etc/pacman.d/hooks" [1] is (at least
> one
> > example) place that will override "/usr/share/libalpm/hooks".
> >
> > The directories/priorities should be enumerated in the docs. Even if this
> > is enumerated in another doc page somewhere, since the behavior really
> > _matters_ in alpm-hooks it should probably be at least re-enumerated here
> > if not become the source-of-record for this information.
> >
> > --Sean
> >
> > [0] https://www.archlinux.org/pacman/alpm-hooks.5.html
> > [1] https://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks
>
> man pacman.conf
>
Reply | Threaded
Open this post in threaded view
|

Re: alpm-hooks: OVERRIDING HOOKS

Eli Schwartz-2
On 03/17/2018 07:38 PM, Sean Enck wrote:

> I figured that it was spelled out somewhere...it is more that whatever that
> one-way doc pattern was going to be (pacman.conf -> alpm-hooks) makes the
> context for understanding the "OVERRIDING HOOKS" section tougher to consume
> from alpm-hooks (e.g. there is no "See Also: pacman.conf").
>
> On Sat, Mar 17, 2018 at 6:43 PM, Andrew Gregory <[hidden email]>
> wrote:
>
>> On 03/17/18 at 10:36pm, Sean Enck wrote:
>>> If you read the "man alpm-hooks" it alludes to a priority-based directory
>>> overriding behavior. But the directory/priority queue for when hooks are
>>> loaded isn't stated [0]
>>>
>>> Some quick searching indicates: "/etc/pacman.d/hooks" [1] is (at least
>> one
>>> example) place that will override "/usr/share/libalpm/hooks".
>>>
>>> The directories/priorities should be enumerated in the docs. Even if this
>>> is enumerated in another doc page somewhere, since the behavior really
>>> _matters_ in alpm-hooks it should probably be at least re-enumerated here
>>> if not become the source-of-record for this information.
>>>
>>> --Sean
>>>
>>> [0] https://www.archlinux.org/pacman/alpm-hooks.5.html
>>> [1] https://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks
>>
>> man pacman.conf
1) Mailing list etiquette is to reply via bottom-posting, this gets
exponentially more confusing when some posters top-post while the rest
bottom post.

2) Hook dirs depend on your configuration file, of course, and more
importantly, they depend on what tool you use to perform upgrades (as
this is responsible for parsing the configuration file, theoretically
doing whatever it wants to the results, and then dealing with libalpm
via that). That being said, patches welcome!

--
Eli Schwartz
Bug Wrangler and Trusted User


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

Re: alpm-hooks: OVERRIDING HOOKS

Sean Enck
On Sat, Mar 17, 2018 at 9:28 PM, Eli Schwartz <[hidden email]>
wrote:

> On 03/17/2018 07:38 PM, Sean Enck wrote:
> > I figured that it was spelled out somewhere...it is more that whatever
> that
> > one-way doc pattern was going to be (pacman.conf -> alpm-hooks) makes the
> > context for understanding the "OVERRIDING HOOKS" section tougher to
> consume
> > from alpm-hooks (e.g. there is no "See Also: pacman.conf").
> >
> > On Sat, Mar 17, 2018 at 6:43 PM, Andrew Gregory <
> [hidden email]>
> > wrote:
> >
> >> On 03/17/18 at 10:36pm, Sean Enck wrote:
> >>> If you read the "man alpm-hooks" it alludes to a priority-based
> directory
> >>> overriding behavior. But the directory/priority queue for when hooks
> are
> >>> loaded isn't stated [0]
> >>>
> >>> Some quick searching indicates: "/etc/pacman.d/hooks" [1] is (at least
> >> one
> >>> example) place that will override "/usr/share/libalpm/hooks".
> >>>
> >>> The directories/priorities should be enumerated in the docs. Even if
> this
> >>> is enumerated in another doc page somewhere, since the behavior really
> >>> _matters_ in alpm-hooks it should probably be at least re-enumerated
> here
> >>> if not become the source-of-record for this information.
> >>>
> >>> --Sean
> >>>
> >>> [0] https://www.archlinux.org/pacman/alpm-hooks.5.html
> >>> [1] https://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks
> >>
> >> man pacman.conf
>
> 1) Mailing list etiquette is to reply via bottom-posting, this gets
> exponentially more confusing when some posters top-post while the rest
> bottom post.
>
> 2) Hook dirs depend on your configuration file, of course, and more
> importantly, they depend on what tool you use to perform upgrades (as
> this is responsible for parsing the configuration file, theoretically
> doing whatever it wants to the results, and then dealing with libalpm
> via that). That being said, patches welcome!
>
> --
> Eli Schwartz
> Bug Wrangler and Trusted User
>
>
1) Sorry, as soon as I hit "Send" I had regrets :/

Ok, so I just want to make sure that I'm clear where we are talking (I may
be making an assumption/reading into your response too deeply, so want to
confirm). libalpm, I know, can/is used by more than pacman. So, yes, maybe
alpm-hooks can't/shouldn't reference pacman.conf in the manpage, certainly
understandable.

Does that mean that:
"Hooks may be overriden by placing a file with the same name in a higher
priority hook directory. Hooks may be disabled by overriding them with a
symlink to /dev/null"

becomes something like (maybe there is a better suggestion here):
"Hooks may be overriden by placing a file with the same name in a higher
priority hook directory as passed to libalpm. Hooks may be disabled by
overriding them with a symlink to /dev/null"

That would be the only thing I would be looking to do/change, are we saying
the same thing and/or am I missing something? I'm not trying to get petty
on the docs/wording, but it's easy to forget (or it was for me) that I'm
talking about the the alpm world and not the pacman world so even a minor
wording change, if there was one, would've jogged my memory ("What passes
hooks to libalpm...? oh yeah...pacman...") and I would've never had to mail
the mailinglist...