Hi,
is there perhaps a GUI to create Ebuilds? I searched around but didn't find one. Whould be great to have a GUI to select the USE flags, set the download URL, the description, select dependencies (a list of the portage-tree where you can click the packages),..

There was one called abeni created by pythonhead, but it is no longer supported or functioning. He was waiting for wx windows2 I think._________________Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch...

I took a look at your gui, and I fear that it is simplifying the ebuild creation process a lot. If you look at some of the ebuilds the build process is fairly complex. The gui would need to support some way to edit the code of the ebuild too. Basically I think what you are aiming to create is an IDE for ebuilds. The initial selection of USE flags, source URI, etc, could be done in a "wizard" phase, and then from then on you could edit the contents of the ebuild.

I'm not sure if Java is the best lang to do this in to make it official, but I may be wrong. I'm just basing this statement on what gentoo tools are official.

I took a look at your gui, and I fear that it is simplifying the ebuild creation process a lot. If you look at some of the ebuilds the build process is fairly complex. The gui would need to support some way to edit the code of the ebuild too. Basically I think what you are aiming to create is an IDE for ebuilds. The initial selection of USE flags, source URI, etc, could be done in a "wizard" phase, and then from then on you could edit the contents of the ebuild.

I'm not sure if Java is the best lang to do this in to make it official, but I may be wrong. I'm just basing this statement on what gentoo tools are official.

I agree completely.

dol-sen wrote:

There was one called abeni created by pythonhead, but it is no longer supported or functioning. He was waiting for wx windows2 I think.

I think the best for this project would be a "simple" GUI that can make basic ebuilds, to make it more accessible for users to roll their own ebuilds. Of course for larger, more complicated packets, more manual interaction would be needed._________________Help the confused! Adopt an unanswered post!
prepend [solved] to your post title when you feel your issue is resolved.
Worcester Judo

well open the template in gVIM/gEDIT/...
there is too much custom stuff to go into a ebuild to warrent an auto-generator GUI_________________The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king

first of all, text editors, manpages and official guides will always be there. This is the reference for us all, and has proved sufficient for creating large numbers of non-trivial ebuilds.

Then again, IDEs are used to achieve increased productivity for complex tasks. An IDE for creating and maintaning ebuilds is an interesting idea, IMHO. For one thing the IDE could do all sorts of validity and formatting checks that we want ebuilds to satisfy. It could also provide context-sensitive help that assists the learning process.

An IDE can be written from scratch of course, but there are also frameworks such as Eclipse. Maybe a framework would gives the IDE designer more time to focus on the core features of the IDE.

Oh well, I have just barely written one ebuild ever, and zero IDEs by the way, so I am really not the expert here ...

I do not think that an ebuild GUI would be a good idea. IMHO, people who write ebuilds should have at least *some* idea as to what does what in an ebuild and how an ebuild works, otherwise there's the chance that we're gonna have people going around complaining that it's not working... i'd hate to see the forums and #gentoo filled with people screaming out "help me! help me! my ebuild for foo didn't compile" and shit like that..._________________Gentoo/BSD, Gentoo/Alt AT and Bugday lead
AMD64, Xfce, Sunrise, www-servers, net-irc, lang-misc, Artwork
If you find a bug, submit it! Bugzilla

I do not think that an ebuild GUI would be a good idea. IMHO, people who write ebuilds should have at least *some* idea as to what does what in an ebuild and how an ebuild works, otherwise there's the chance that we're gonna have people going around complaining that it's not working... i'd hate to see the forums and #gentoo filled with people screaming out "help me! help me! my ebuild for foo didn't compile" and shit like that...

A complete rubbish argument.
There are three filtering mechanisms to prevent stuff like that: Bugzilla (on which ebuilds have to be submitted to be included with official portage), Sunrise (unofficial user community portage tree, which is not supported in any way, use at your own risk and by the time you know how to use it you know about that) and the ebuild quiz's/mentoring period (to make you an official dev, which requires real knowledge).

On the other hand, a GUI tool can greatly reduce the time creating a complex ebuild. With other words: a GUI tool is not a "noob tool" per se, but can easely be used by non-vim zealot developers. This overal has a positive effect on increasing the portage tree and quality of the ebuilds (since they are generated, not manually written... which is another argument against your argumentation).

Explain to me how you'll be able to fit all of that in a simple and easy-to-use GUI wizard.

That might be difficult, but I don't think it would be a unovercomeble task. Remember, we don't live in 1995 anymore and we can make such a GUI kinda intelligent in using USE flags. It could for example guestimate the USE flags running a ./config or something.

It could for example guestimate the USE flags running a ./config or something.

And can, quite possibly, miss or choose incorrect USE flags. And the user might be an idiot who doesn't go over it. That would then result in something along the lines of everyone complaining "My dog just made an ebuild and it doesn't work!! Oh noes!!!11111cos(0)".

Other than the great number of possible flaws, we don't want everyone and their dogs making crap ebuilds. Not to mention this is a lot of development power going to waste._________________meow.

It could for example guestimate the USE flags running a ./config or something.

And can, quite possibly, miss or choose incorrect USE flags. And the user might be an idiot who doesn't go over it. That would then result in something along the lines of everyone complaining "My dog just made an ebuild and it doesn't work!! Oh noes!!!11111cos(0)".

Other than the great number of possible flaws, we don't want everyone and their dogs making crap ebuilds. Not to mention this is a lot of development power going to waste.

It could for example guestimate the USE flags running a ./config or something.

And can, quite possibly, miss or choose incorrect USE flags. And the user might be an idiot who doesn't go over it. That would then result in something along the lines of everyone complaining "My dog just made an ebuild and it doesn't work!! Oh noes!!!11111cos(0)".

Other than the great number of possible flaws, we don't want everyone and their dogs making crap ebuilds. Not to mention this is a lot of development power going to waste.

See my answer to welp, I hate to repeat myself.

Fine; see below.

Q-collective wrote:

This overal has a positive effect on increasing the portage tree and quality of the ebuilds (since they are generated, not manually written... which is another argument against your argumentation).

I doubt generated ebuilds would be anywhere near those created by great devs in terms of quality. Don't forget that a lot of ebuilds need extra/complex stuff, and not basic default methods, so the generator won't be able to do those. (Don't argue that we'll be able to create this, because we won't. At least not anytime soon.)_________________meow.

This overal has a positive effect on increasing the portage tree and quality of the ebuilds (since they are generated, not manually written... which is another argument against your argumentation).

I doubt generated ebuilds would be anywhere near those created by great devs in terms of quality. Don't forget that a lot of ebuilds need extra/complex stuff, and not basic default methods, so the generator won't be able to do those. (Don't argue that we'll be able to create this, because we won't. At least not anytime soon.)

Generators can create very complex yet very correct stuff, see DreamWeaver for example that can create very complex yet perfectly coded websites(and don't say DreamWeaver is bad just because you don't like it, because millions of others do).
So, in short, no one has come up with any real arguments against a GUI Ebuild creator yet. And still the advantages are numerous:
- Fast way to create correctly coded (complex) ebuilds.
- Which in turn has a positive effect on getting the portage tree bigger.
- Anyone can create ebuilds without reading piles of documentation.
- The ebuild maintainers have an easier task maintaining ebuilds.
- Lesser maintainers needed for a bigger portage tree.
- Lesser bugs because code is generated and not manually written (it's a well known fact that 90+% of all errors and bugs are pebkac related).
- Gentoo can finally become a real community driven project with several stages of participation: user (someone who can create an ebuild and can post that on bugzilla), trusted user (sunrise powers) and developer. Now we only have developer and we're just starting with trusted user, but a lot of users are still scared away because of the piles of documentation you need to get through before you know anything about portage. A GUI can make that process of learning more fluent.
- In the end: more developers, because you embrace more users and make the learning curve less steep.
- More developers working on Gentoo, because lesser devs are needed to maintain the portage tree. So faster development.
- Profit!

Generators can create very complex yet very correct stuff, see DreamWeaver for example that can create very complex yet perfectly coded websites(and don't say DreamWeaver is bad just because you don't like it, because millions of others do).

Speaking of apps such as DreamWeaver, don't forget that a lot is up to the user, and therefore, with valid code, a site can still be complete crap. The same can apply to an ebuild.

I'll look at the specifics of your post after I complete my homework._________________meow.

Generators can create very complex yet very correct stuff, see DreamWeaver for example that can create very complex yet perfectly coded websites(and don't say DreamWeaver is bad just because you don't like it, because millions of others do).

Speaking of apps such as DreamWeaver, don't forget that a lot is up to the user, and therefore, with valid code, a site can still be complete crap. The same can apply to an ebuild.

Q-collective wrote:

There are three filtering mechanisms to prevent stuff like that: Bugzilla (on which ebuilds have to be submitted to be included with official portage), Sunrise (unofficial user community portage tree, which is not supported in any way, use at your own risk and by the time you know how to use it you know about that) and the ebuild quiz's/mentoring period (to make you an official dev, which requires real knowledge).

Generators can create very complex yet very correct stuff, see DreamWeaver for example that can create very complex yet perfectly coded websites

I'm pretty sure I read a magazine which built a website with Dreamweaver, then went in to take a look at the code and found that a whole load of tags were... wrong... out-of-date, whatever, IMO, that's not a perfectly coded website._________________Gentoo/BSD, Gentoo/Alt AT and Bugday lead
AMD64, Xfce, Sunrise, www-servers, net-irc, lang-misc, Artwork
If you find a bug, submit it! Bugzilla