1 |
On Wed, 08 Oct 2008 19:48:56 +0100 |
2 |
Steve Long <slong@××××××××××××××××××.uk> wrote: |
3 |
> > The whole point of PMS is that it provides a way to avoid relying |
4 |
> > upon implementation specific things. There are currently no |
5 |
> > packages that rely upon calling phase functions in the wrong place |
6 |
> |
7 |
> It wasn't about calling it in the wrong place, it was about how you |
8 |
> test for whether the ebuild+eclasses provide a function, or use a |
9 |
> phase. |
10 |
|
11 |
The two issues are the same. |
12 |
|
13 |
> > and there are |
14 |
> > good reasons a package manager might want to avoid implementing |
15 |
> > things in a way such that doing so is legal, so we don't allow it. |
16 |
> |
17 |
> Sure let's keep constraining what the bash side of things can do, as |
18 |
> that's nothing to do with the package manager implementation. |
19 |
|
20 |
There are lots of constraints on what the bash side can do that are |
21 |
for package manager implementation sanity reasons. The whole |
22 |
constant cache requirement thing, for example, is purely a side effect |
23 |
of how package managers work. |
24 |
|
25 |
> > Also, I don't think it has to be done at that point. I think it's |
26 |
> > convenient to do it at that point, and when combined with several |
27 |
> > other reasons doing it that way is the best option. |
28 |
> > |
29 |
> Yes, a mystery wrapped in an enigma wrapped in pure bullsh^W |
30 |
> obfuscation is always such fun. |
31 |
|
32 |
We were discussing your trollish claim that I thought that things had to |
33 |
be done a particular way. It is of course highly obvious that there are |
34 |
several ways of achieving the desired result, and highly obvious that |
35 |
there are a whole bunch of factors affecting which one works best. |
36 |
|
37 |
As it happens, all three package managers picked different solutions, |
38 |
all based upon extremely obscure internals issues. Which brings me back |
39 |
to my original point -- mandating a particular behaviour to enable some |
40 |
horrible ebuild hackery that doesn't even do what people want would be |
41 |
a very silly decision. |
42 |
|
43 |
> > Strange how you repeatedly seem to pop up in favour of doing |
44 |
> > whatever you think will cause most inconvenience to Paludis, |
45 |
> > though... |
46 |
> > |
47 |
> Strange how you think you can read my mind.. I actually think that not |
48 |
> providing functions an ebuild might call in a phase, during the actual |
49 |
> install, is not such a good way for the mangler to ascertain ahead of |
50 |
> time whether or not that phase will be needed, *irrespective* of how |
51 |
> any extant implementation does it. |
52 |
|
53 |
Your premise is faulty. Ebuilds may not call phase functions, and |
54 |
never do. |
55 |
|
56 |
> I actually hesitated to get into that discussion with you. I did so |
57 |
> as I wanted to query the design decision. You know, a technical |
58 |
> _discussion_.. Thanks for reminding me again how incapable of that |
59 |
> you are, unless you think there is some political capital to be |
60 |
> gained. |
61 |
|
62 |
If you want a technical discussion, post using your other account with |
63 |
your real name on it, not your sockpuppet. It's a bit hard to take you |
64 |
seriously when you maintain two personas, one for real development and |
65 |
an alterego for Pkgcore fanboyism / Paludis bashing. |
66 |
|
67 |
-- |
68 |
Ciaran McCreesh |