1 |
On Sunday 19 September 2004 16:56, Dan Armak wrote: |
2 |
> On Sunday 19 September 2004 07:43, Duncan wrote: |
3 |
> > Then, at the top of the file put a big hairy warning about how some |
4 |
> > package components, particularly in kdebase, are depended on by others, |
5 |
> > and to disable the use flag and recompile all packages if there are |
6 |
> > dependency issues, and then leave everything else up to the user. Any |
7 |
> > bugs on related dependency issues would be marked invalid, see the |
8 |
> > warning in the file, etc. so it wouldn't become a big support issue. |
9 |
> |
10 |
> As you say, this solution is hairy (or anything else that doesn't create |
11 |
> real separate ebuilds for the separate apps). I personally don't like it at |
12 |
> all and don't really want to see it happen even as an alternative to |
13 |
> nothing at all, because it's so ugly. Of course, it's very easy to |
14 |
> implement, but it takes away all the advantages of having a proper package |
15 |
> manager - all the advantages of using portage rather than state-less |
16 |
> invocations on the order of 'ebuild.sh file.ebuild'... |
17 |
> |
18 |
> And of course this solution entails more or less not supporting it despite |
19 |
> having it in the portage tree - marking related bugs as invalid etc. That's |
20 |
> another reason I don't like it. |
21 |
> |
22 |
> Perhaps I don't have the right to say this at this point, having been |
23 |
> incative for over a year, but this solution simply takes away too much |
24 |
> functionality and support from the user in order to decrease the |
25 |
> maintainer's workload. |
26 |
|
27 |
Well, I'll second you in any case. It is not a solution and offering something |
28 |
willingly and then saying it is unsupported is in these kinds of cases a |
29 |
medicine worse than the cure. The only "possible" solution I see would |
30 |
involve useflags and useflag dependencies (still "in the works"). But I agree |
31 |
that we must avoid in any case to get back the stateless mess that the lack |
32 |
of dependency tracking entails. |
33 |
|
34 |
Paul |
35 |
|
36 |
-- |
37 |
Paul de Vrieze |
38 |
Gentoo Developer |
39 |
Mail: pauldv@g.o |
40 |
Homepage: http://www.devrieze.net |