| 1 |
On Mon, 24 Jul 2006 13:52:23 -0400 |
| 2 |
Mike Kelly <pioto@×××××.org> wrote: |
| 3 |
|
| 4 |
> On Sat, 22 Jul 2006 22:39:28 -0700 |
| 5 |
> Brian Harring <ferringb@×××××.com> wrote: |
| 6 |
> > > I still think that those hooks should go into the tree rather than |
| 7 |
> > > being installed by packages. |
| 8 |
> > |
| 9 |
> > They're called eclasses ;) |
| 10 |
|
| 11 |
Good argument ;) |
| 12 |
|
| 13 |
> The problem with having these in the tree is that they should be able |
| 14 |
> to take advantage of the unique features of each package manager. |
| 15 |
> Otherwise, they really are just eclasses. |
| 16 |
|
| 17 |
"unique features" such as? What exact benefits does this hooks system |
| 18 |
give you over using an eclass? |
| 19 |
|
| 20 |
> > It also has the drawback that via transferring control over to the |
| 21 |
> > tree, the pkg manager cannot do proper cleanup. |
| 22 |
> > |
| 23 |
> > What you say? |
| 24 |
> > |
| 25 |
> > What happens if $PKGMANGER adds user blah for building xyz, xyz |
| 26 |
> > fails? Proper course of action would be to punt this unused user if |
| 27 |
> > it's refcount is just xyz, no? |
| 28 |
> > |
| 29 |
> > Transfer control of fundamental features like that to delegation |
| 30 |
> > hooks, you either have to add more hooks so the delegation target |
| 31 |
> > can cleanup after itself, or you plain don't do cleanup. |
| 32 |
|
| 33 |
If you were replying to me I don't see how this is affected by the |
| 34 |
location of the hooks but the general concept. You have the same problem |
| 35 |
independent where they would live. |
| 36 |
|
| 37 |
Marius |
| 38 |
|
| 39 |
-- |
| 40 |
Public Key at http://www.genone.de/info/gpg-key.pub |
| 41 |
|
| 42 |
In the beginning, there was nothing. And God said, 'Let there be |
| 43 |
Light.' And there was still nothing, but you could see a bit better. |
Archives