| 1 |
On Mon, 24 Jul 2006 16:41:26 -0400 |
| 2 |
Mike Kelly <pioto@×××××.org> wrote: |
| 3 |
|
| 4 |
> On Mon, 24 Jul 2006 21:22:20 +0200 |
| 5 |
> Marius Mauch <genone@g.o> wrote: |
| 6 |
> |
| 7 |
> > > The problem with having these in the tree is that they should be |
| 8 |
> > > able to take advantage of the unique features of each package |
| 9 |
> > > manager. Otherwise, they really are just eclasses. |
| 10 |
> > |
| 11 |
> > "unique features" such as? What exact benefits does this hooks |
| 12 |
> > system give you over using an eclass? |
| 13 |
> |
| 14 |
> The biggest one is the ability to clean up after myself if the emerge |
| 15 |
> fails (if the fail hooks idea I mentioned in my previous mail makes |
| 16 |
> sense, at least). |
| 17 |
> |
| 18 |
> Basically, what I need to do is: |
| 19 |
> |
| 20 |
> - Run a script to intelligently add / manage package manager-added |
| 21 |
> users. At the moment, it would seem this should just be run before |
| 22 |
> or during the pkg_setup phase, but this may well be sub-optimal, |
| 23 |
> particularly in the case if binary packages or non-standard ROOTs. |
| 24 |
|
| 25 |
can be done within an eclass. |
| 26 |
|
| 27 |
> - Properly let that set of scripts know when an added user or group |
| 28 |
> is safe to remove. This code is intimately tied with the |
| 29 |
> implementation-specific details of the above scripts, which may |
| 30 |
> change from version to version, hence my trepidation about adding |
| 31 |
> this code directly into portage itself. |
| 32 |
|
| 33 |
can be done with an eclass too. Also that eclass can depend on your |
| 34 |
scripts or whatever package it needs to do this, seems better than to |
| 35 |
add dependencies in every package using this functionality. |
| 36 |
Also should be able to have a generic interface for this. |
| 37 |
|
| 38 |
> - Have the ability to clean up from myself if a build goes awry, or |
| 39 |
> is aborted by the operator. As far as I know, this particular |
| 40 |
> requirement would exclude the use of eclasses, but I could well be |
| 41 |
> wrong. |
| 42 |
|
| 43 |
Don't see how the proposed hook system would allow that either without |
| 44 |
additional mods in abort_handler. |
| 45 |
|
| 46 |
> - Have this user addition handled in an intelligent way when we're |
| 47 |
> only building/installing a binary package. I'm not really sure on |
| 48 |
> what would be a logical way to do this. |
| 49 |
|
| 50 |
Yeah, that one is tricky. |
| 51 |
|
| 52 |
> So, if the answer to the above is to not use some sort of hooks, then |
| 53 |
> I would appreciate pointers on where to look to achieve all of the |
| 54 |
> above with portage. |
| 55 |
|
| 56 |
Well, I'm not saying to not use hooks, just trying to find the (IMHO) |
| 57 |
best solution to the problem (and being a bit resistant against an |
| 58 |
generic unprotected hook system). |
| 59 |
From my POV this project should work like you provide a service (your |
| 60 |
management scripts) and portage/paludis/whatever use this service by |
| 61 |
calling the scripts. This would mean you wouldn't really have to care |
| 62 |
about the glue code but just provide an interface, and the pkgmanager |
| 63 |
has to conform to that interface. |
| 64 |
Right now it sounds like you want to work on the glue code, might be |
| 65 |
better to define the interface first. |
| 66 |
|
| 67 |
Btw, you haven't really answered my question, what benefits do you/we |
| 68 |
get by having implementation specific hooks instead of using an |
| 69 |
eclass/repo level hook system (that "unique features" bit)? |
| 70 |
|
| 71 |
Marius |
| 72 |
|
| 73 |
-- |
| 74 |
Public Key at http://www.genone.de/info/gpg-key.pub |
| 75 |
|
| 76 |
In the beginning, there was nothing. And God said, 'Let there be |
| 77 |
Light.' And there was still nothing, but you could see a bit better. |
Archives