On Thu, Apr 07, 2005 at 07:28:31PM +0200, Adrian Lambeck wrote:
> Everybody thanks for the feedback to my GLEP(35).
> The discussion about it started on 2005/03/13.
> What I figured out so far is that some proposed changes are already covered 
> in 
> repoman.That is even better because some of the work is already done then. 
> But how come that there are still trivial errors if half of the GLEP is 
> covered and everybody is using repoman?

Define some, and the additional checks.

The listed checks in the glep are all handled by repoman, with the 
sole exception of detecting stale SRC_URI; if I ever got off my ass 
and dusted off pchecker and poked infra about running it occasionally, 
that would be covered also.

re: broken shell scripts with invalid/missing commands, how are you 
going to detect this?  bash -n of the ebuild will not suffice for 
syntax check errors, mainly due to the increasing (ab|)use of extglob 
in ebuilds/eclasses...

Aside from that, the only errors I don't personally hold an ebuild 
maintainer responsible for is either A) eclass dev goes and breaks 
backwards compatibility (bad bad bad bad), or B) src_uri goes stale.
Everything else pretty much falls on the maintainers head imo.

Elaborate on cyclic depends also; there's nothing wrong with packages 
directly depending on each other.  Consider gcc, you can't build a gcc 
without a compiler... cyclic depends right there...
(technically rdepend on a gcc version, but neh).

> I agree that changes on ebuilds should be done only by the developers. I will 
> change this point in the GLEP.
> To post errors to a website and send some mails is just a form of 
> implementation that I do not worry about right now. To use both and let dev`s 
> choose from it would be a good thing though.
> Somebody mentioned that I am not aware of gentoo dev practices. That`s right.
> I tried to become aware of it but I could not find anything useful. Maybe I 
> have not found the right documents or there are none i.e. I do not want to 
> read portage source to figure out what is going on.

Err... while I berate the hell out of portage source on a daily basis 
(it's my usual whipping boy), these checks you've referenced are all 
repoman based, and repoman --help requires no code reading :)

> Maybe I should also add some motivation why to do this:
> There have been some talks about bringing Gentoo to the enterprise. For me 
> this is not important and I do not care but this will never work if the 
> quality is not checked at least to some degree. 
> Also I do not like the mentality somebody put up that was like this: "I don`t 
> mind fixing wrong URL`s - it is a matter of seconds."
> If you work for some customer (i.e. gentoo users) and they find simple errors 
> that they might fix by themselves. What might they think ?
> Why not "kill" all these errors faster and take upon the hard things?
> I hate to open a root shell, fix the error, run the command again (find 
> another 
> error ?), start up firefox, login to bugs, check if somebody caught the 
> error, file a bug .... hope you get the point.

I might be daft, but I'm not exactly hitting these errors...
The errors I *do* hit are more then simple stupid goof-ups people 
should've caught, they're usual logic errors or an unforeseen 
nastyness the packages build system busts out (sandbox violations 

> It might be possible that i.e. for ONE week one developer is responsible for 
> fixing ALL broken URL`s of all packages (does he really need to know about 
> the ebuild`s content ?). Although I don`t know how many broken URL`s there 
> might be ...
URI scanning is one thing, I'm just wondering what the rest of the 
glep is actually specifying... Specifics are needed.

> Please do not get me wrong like: somebody from "outside" tries to change the 
> system. I love Gentoo and I think it is a great system but there are things I 
> would like to improve.

Change comes from inside and out, doesn't matter where from just as 
long as the goal is improvement :)

That said, I still have qualms about the glep :)
gentoo-dev@gentoo.org mailing list

Reply via email to