On Mon, 24 Jul 2006 16:41:26 -0400 Mike Kelly <[EMAIL PROTECTED]> wrote:
> On Mon, 24 Jul 2006 21:22:20 +0200 > Marius Mauch <[EMAIL PROTECTED]> wrote: > > > > The problem with having these in the tree is that they should be > > > able to take advantage of the unique features of each package > > > manager. Otherwise, they really are just eclasses. > > > > "unique features" such as? What exact benefits does this hooks > > system give you over using an eclass? > > The biggest one is the ability to clean up after myself if the emerge > fails (if the fail hooks idea I mentioned in my previous mail makes > sense, at least). > > Basically, what I need to do is: > > - Run a script to intelligently add / manage package manager-added > users. At the moment, it would seem this should just be run before > or during the pkg_setup phase, but this may well be sub-optimal, > particularly in the case if binary packages or non-standard ROOTs. can be done within an eclass. > - Properly let that set of scripts know when an added user or group > is safe to remove. This code is intimately tied with the > implementation-specific details of the above scripts, which may > change from version to version, hence my trepidation about adding > this code directly into portage itself. can be done with an eclass too. Also that eclass can depend on your scripts or whatever package it needs to do this, seems better than to add dependencies in every package using this functionality. Also should be able to have a generic interface for this. > - Have the ability to clean up from myself if a build goes awry, or > is aborted by the operator. As far as I know, this particular > requirement would exclude the use of eclasses, but I could well be > wrong. Don't see how the proposed hook system would allow that either without additional mods in abort_handler. > - Have this user addition handled in an intelligent way when we're > only building/installing a binary package. I'm not really sure on > what would be a logical way to do this. Yeah, that one is tricky. > So, if the answer to the above is to not use some sort of hooks, then > I would appreciate pointers on where to look to achieve all of the > above with portage. Well, I'm not saying to not use hooks, just trying to find the (IMHO) best solution to the problem (and being a bit resistant against an generic unprotected hook system). From my POV this project should work like you provide a service (your management scripts) and portage/paludis/whatever use this service by calling the scripts. This would mean you wouldn't really have to care about the glue code but just provide an interface, and the pkgmanager has to conform to that interface. Right now it sounds like you want to work on the glue code, might be better to define the interface first. Btw, you haven't really answered my question, what benefits do you/we get by having implementation specific hooks instead of using an eclass/repo level hook system (that "unique features" bit)? Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better.
signature.asc
Description: PGP signature
