Re: [gentoo-dev] Community driven meta distribution or only distribution (was Re: Several portage trees)

[Henti Smith]

> Seeing this. I have a specific request to make. Could you please ensure
> that your ebuilds are tagged with the 'EBUILD' keyword, to make them
> easier to find firstly. Secondly, just as an idea, a developer that has
> some time to go thru submitted ebuilds and review them for style and
> correctness (as I did for the ebuild mentioned above in this thread).

I do this .. however I see your point.

> My comments were included below in my previous email. I have also
> attached them to the bug item now.

could this and others "requirements" for a ebuild to be accepted not be put into proper documentation
and added to the gentoo site. 

> lintool/repoman do remind you that some of those are required, but for
> the most part they require a human to check. The original ebuild looked
> as if it was written using only the guide, and none of the existing
> ebuilds in portage, many of which server as excellent examples of ebuild
> style and how things are done.
> However you are partially correct that some of this should be added to
> [1].
> most importantly,
> - say required items SLOT/KEYWORDS/IUSE/HOMEPAGE
> - say that all documentation should be installed
> - recommend econf/emake/einstall instead of normal variants
> - patch+src_unpack is not efficent and maybe incorrect, use PATCHES="..."

I have used the guide/skel/ebuilds to write the ebuilds I have done. I however do not expect them to be 
the best or maybe even acceptable since there is so many different "styles" of doing ebuilds. 

which ebuilds can be used for referance? once again a guide would be a good thing at this point.
I'm by no means a linux developer, I'm but a user that can do scripting and figure things out given 
enought information. providing the information to do things correcly can greatly relieve full time developers
from having to deal with broken ebuilds as active ebuilders can help fix problems they have experianced before.

> Some of the things I mentioned are also partially my personal
> preferences to make life easier on myself. People's code says a lot
> about them generally, and if your submitted ebuilds look sloppy and
> that lessens the chance that developers will even go thru them and
> say what is wrong, let along clean them up.

everybody has to start somewhere ;PP 
some just take longer to learnt he correct way and need a little more attention .. but in the end the effort 
can pay off and make everybodies lives easer.

> Attaching a simple text file with just your changelog entry would be
> sufficent if you are updating an existing package, or including a new
> changelog from the skeleton file for a new ebuild. (This is a personal
> preference again).

It's still a good pointer.. 

If need be I will start writing a "ebuild developers howto" to get all the information 
together and get some base for new and existing ebuilders to work off. The way an ebuild is developed / coded / created 
really should be on par and consistant with how portage works and features it supports. legacy support is a good thing, but left for to long
without havin proper guidelines will only agrivate the situation which I acuallt think it has judging by your comment regarding using only the ebuild guide.

People should be capabile of writing an ebuil dusing ONLY the ebuilde guide and not need to go throught 4000 ebuilds to find what the best and latest way of doing things are.

> Repoman replaced lintool. I don't unfortunetly know of a tool that users
> can use to check ebuilds themselves, as repoman requires a CVS checkout.
> I have said previously that lintool needs to come back myself, and I
> have submitted some fixes for it to bugzilla myself. That document [2]
> does appear to contradict itself.

Human eyes are always the best way... I habe mentioned before having an ebuild mailling list. 
I do really think the ebuild situation is becomming like a software package on it's own with a core set of developers that can commit changes 
and users on the mailling list offering support and helping each other get their stuff working without having the bug the developers all the time to 
get things working .. 

creating a tree of developers -> experianced ebuilders -> new ebuilders in a mailling list can help solve problems as it can be a central place to "promote" ebuild for 
testing before going into bugzilla until a ebuilder has had the experiance and "well wishes" of he's peers that he's reached a point where he can manage on he's own. in turn he then start helping people with ebuild development problems and "training" new ebuilders. in the end the develop interaction is really only at the bugzilla stage where incorporating into the portage tree is needed. by then an ebuild has been looked at by other ebuilders and helped get into a shape that is correct and tought the ebuild creator new things about how to create a correct ebuild. 

> I personally try to avoid packages that do not fill at least one of the
> following requirements:
> 1) is actively maintained
> 2) is widely used
> 3) not directly useful to myself
>
> the reasoning behind 1) is that unmaintained packages upstream of Gentoo
> do cause problems. media-plugins/avi-xmms is a recent example. It is
> presently masked in packages.mask while it dies down further, at which
> point if it is no maintained again, it will probably be trimmed from the
> tree.

If nobody is using the application then sure I understand drop the support and ebuild from the tree, but 
as the mail shows there is somebody and he's more then willing to help and work at keeping something he wants.
IF he doesn't know how a guide and/or system must be in place to provide the user with the knowledge and means to 
have he's contribution accepted into the tree. 

> For 2) packages that aren't actively maintained, but are widely used
> usually have enough other support and people working with them that it
> is possible to support them ourselves. An active and responsive mailing
> list for a package fills this well, or if there are good pages written
> up about the package on the web. Several actively maintained packages that
> use the library as a requirement would also serve to show that it is
> still in general use.
>
> Item 3) is somewhat different than the other two. If there is a package
> that doesn't fit into the other two, and I have a personal everyday use
> for it, I'm willing to put some of my time to keeping it working.

If each user can be a developer in he's own mind and has access to the right tools and information 
no package will fall into disuse as there will be somebody out there using it. Such is the way of choice :) 

Hope this is taken as suggestions and user input and nothing more .. or less :) 

Henti 

--
gentoo-dev@g.o mailing list