Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Thanks for your feedback
Date: Fri, 08 Apr 2005 10:13:57
Message-Id: 20050408101436.GJ14728@exodus.wit.org
In Reply to: [gentoo-dev] Thanks for your feedback by Adrian Lambeck
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