1 |
On Thu, Apr 07, 2005 at 07:28:31PM +0200, Adrian Lambeck wrote: |
2 |
> Everybody thanks for the feedback to my GLEP(35). |
3 |
> The discussion about it started on 2005/03/13. |
4 |
> |
5 |
> What I figured out so far is that some proposed changes are already covered in |
6 |
> repoman.That is even better because some of the work is already done then. |
7 |
> But how come that there are still trivial errors if half of the GLEP is |
8 |
> covered and everybody is using repoman? |
9 |
|
10 |
Define some, and the additional checks. |
11 |
|
12 |
The listed checks in the glep are all handled by repoman, with the |
13 |
sole exception of detecting stale SRC_URI; if I ever got off my ass |
14 |
and dusted off pchecker and poked infra about running it occasionally, |
15 |
that would be covered also. |
16 |
|
17 |
re: broken shell scripts with invalid/missing commands, how are you |
18 |
going to detect this? bash -n of the ebuild will not suffice for |
19 |
syntax check errors, mainly due to the increasing (ab|)use of extglob |
20 |
in ebuilds/eclasses... |
21 |
|
22 |
Aside from that, the only errors I don't personally hold an ebuild |
23 |
maintainer responsible for is either A) eclass dev goes and breaks |
24 |
backwards compatibility (bad bad bad bad), or B) src_uri goes stale. |
25 |
Everything else pretty much falls on the maintainers head imo. |
26 |
|
27 |
|
28 |
Elaborate on cyclic depends also; there's nothing wrong with packages |
29 |
directly depending on each other. Consider gcc, you can't build a gcc |
30 |
without a compiler... cyclic depends right there... |
31 |
(technically rdepend on a gcc version, but neh). |
32 |
|
33 |
|
34 |
> I agree that changes on ebuilds should be done only by the developers. I will |
35 |
> change this point in the GLEP. |
36 |
> To post errors to a website and send some mails is just a form of |
37 |
> implementation that I do not worry about right now. To use both and let dev`s |
38 |
> choose from it would be a good thing though. |
39 |
> |
40 |
> Somebody mentioned that I am not aware of gentoo dev practices. That`s right. |
41 |
> I tried to become aware of it but I could not find anything useful. Maybe I |
42 |
> have not found the right documents or there are none i.e. I do not want to |
43 |
> read portage source to figure out what is going on. |
44 |
|
45 |
Err... while I berate the hell out of portage source on a daily basis |
46 |
(it's my usual whipping boy), these checks you've referenced are all |
47 |
repoman based, and repoman --help requires no code reading :) |
48 |
|
49 |
|
50 |
> Maybe I should also add some motivation why to do this: |
51 |
> There have been some talks about bringing Gentoo to the enterprise. For me |
52 |
> this is not important and I do not care but this will never work if the |
53 |
> quality is not checked at least to some degree. |
54 |
> |
55 |
> Also I do not like the mentality somebody put up that was like this: "I don`t |
56 |
> mind fixing wrong URL`s - it is a matter of seconds." |
57 |
> If you work for some customer (i.e. gentoo users) and they find simple errors |
58 |
> that they might fix by themselves. What might they think ? |
59 |
> Why not "kill" all these errors faster and take upon the hard things? |
60 |
> I hate to open a root shell, fix the error, run the command again (find another |
61 |
> error ?), start up firefox, login to bugs, check if somebody caught the |
62 |
> error, file a bug .... hope you get the point. |
63 |
|
64 |
I might be daft, but I'm not exactly hitting these errors... |
65 |
The errors I *do* hit are more then simple stupid goof-ups people |
66 |
should've caught, they're usual logic errors or an unforeseen |
67 |
nastyness the packages build system busts out (sandbox violations |
68 |
fex). |
69 |
|
70 |
|
71 |
> It might be possible that i.e. for ONE week one developer is responsible for |
72 |
> fixing ALL broken URL`s of all packages (does he really need to know about |
73 |
> the ebuild`s content ?). Although I don`t know how many broken URL`s there |
74 |
> might be ... |
75 |
URI scanning is one thing, I'm just wondering what the rest of the |
76 |
glep is actually specifying... Specifics are needed. |
77 |
|
78 |
> Please do not get me wrong like: somebody from "outside" tries to change the |
79 |
> system. I love Gentoo and I think it is a great system but there are things I |
80 |
> would like to improve. |
81 |
|
82 |
Change comes from inside and out, doesn't matter where from just as |
83 |
long as the goal is improvement :) |
84 |
|
85 |
That said, I still have qualms about the glep :) |
86 |
~brian |
87 |
-- |
88 |
gentoo-dev@g.o mailing list |