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.

Please stop going in circles, it makes me dizzy.
Is that really the only argument you guys have?

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.

Please stop going in circles, it makes me dizzy.
Is that really the only argument you guys have?

You're only saying that 'cos you know it's a good argument... *nod*_________________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'd have to see a prototype before I believe the "correctly coded (complex)" part. Unless this generator has some super-duper AI powers, I doubt this would happen. How would it know when to use eclasses? How would it know which docs should be excluded? Do you think you can really make ebuilds such as the mozilla-firefox one with a generator?

Q-collective wrote:

- Which in turn has a positive effect on getting the portage tree bigger.

Don't forget that most developers don't like to maintain packages they don't like.

Q-collective wrote:

- Anyone can create ebuilds without reading piles of documentation.

Which isn't necessarily a good thing. How would they know if the generator did a good job?

Q-collective wrote:

- The ebuild maintainers have an easier task maintaining ebuilds.

Most version bumps include only minor changes anyways. Plus the ebuild maintainers still have to fix bugs with the packages. There is a lot more to the tree than ebuilds. (stabilising, fixing bugs, etc.)

Q-collective wrote:

- Lesser maintainers needed for a bigger portage tree.

See above.

Q-collective wrote:

- 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).

See first point in this post.

Q-collective wrote:

- 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.

People can already upload ebuilds to bugzilla. People can already commit to Sunrise. People can already become developers. Your point?

Q-collective wrote:

- In the end: more developers, because you embrace more users and make the learning curve less steep.

Developers should be able to manually make ebuilds and not only be able to fill some crap in a generator. So unless we want worse developers, this is silly.

Q-collective wrote:

- More developers working on Gentoo, because lesser devs are needed to maintain the portage tree. So faster development.

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).

I thought you were the one arguing that a GUI would make the tree bigger - seems to me you're contradicting yourself here... Anyway, are you forgetting about overlays? If people can fill up their overlays with random pakages, they can also kill their tree... even the devs have done it... What if they have a circular dep they can't resolve? How will the user/GUI know whether to use DEPEND, RDEPEND or PDEPEND - in fact, I saw someone asking for help for ages in #gentoo-dev-help on freenode, without getting an answer about a circular dep... they just needed to use PDEPEND. (Hardly anyone knows about it... )_________________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'd have to see a prototype before I believe the "correctly coded (complex)" part. Unless this generator has some super-duper AI powers, I doubt this would happen. How would it know when to use eclasses? How would it know which docs should be excluded? Do you think you can really make ebuilds such as the mozilla-firefox one with a generator?

Valid questions, but not arguments against it.

Quote:

Q-collective wrote:

- Which in turn has a positive effect on getting the portage tree bigger.

Don't forget that most developers don't like to maintain packages they don't like.

Don't forget that because you create a less steep learning curve you'll get more developers in the long run.

Quote:

Q-collective wrote:

- Anyone can create ebuilds without reading piles of documentation.

Which isn't necessarily a good thing. How would they know if the generator did a good job?

Bugzilla knows.

Quote:

Q-collective wrote:

- The ebuild maintainers have an easier task maintaining ebuilds.

Most version bumps include only minor changes anyways. Plus the ebuild maintainers still have to fix bugs with the packages. There is a lot more to the tree than ebuilds. (stabilising, fixing bugs, etc.)

Very true, but my argument still stands, doesn't it?

Quote:

Q-collective wrote:

- Lesser maintainers needed for a bigger portage tree.

See above.

See above.

Quote:

Q-collective wrote:

- 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).

See first point in this post.

A generator can ofcourse have bugs, that's why we have bugzilla, right?

Quote:

Q-collective wrote:

- 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.

People can already upload ebuilds to bugzilla. People can already commit to Sunrise. People can already become developers. Your point?

Quote:

A GUI can make that process of learning more fluent.

Is reading so hard?

Quote:

Q-collective wrote:

- In the end: more developers, because you embrace more users and make the learning curve less steep.

Developers should be able to manually make ebuilds and not only be able to fill some crap in a generator. So unless we want worse developers, this is silly.

Wrong. My point is that you make the learning curve lesser steep, so more people will participate in making ebuilds and are therefor more quickly invited to learn something about the code and documentation behind it. Thusly: more developers in the long run.

Quote:

Q-collective wrote:

- More developers working on Gentoo, because lesser devs are needed to maintain the portage tree. So faster development.

See above.

See above.

Quote:

Q-collective wrote:

- Profit!

I don't understand this last one.

It was a little pun, but more developers are obviously better for Gentoo as a whole.

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).

I thought you were the one arguing that a GUI would make the tree bigger - seems to me you're contradicting yourself here...

Howso? Bugzilla is a good filtering system; it filters out the bad ebuilds. On the other hand there will also be more ebuilds submitted, with lesser bugs, so more ebuilds get committed to portage and thus the tree gets larger.

Quote:

Anyway, are you forgetting about overlays? If people can fill up their overlays with random pakages, they can also kill their tree... even the devs have done it... What if they have a circular dep they can't resolve? How will the user/GUI know whether to use DEPEND, RDEPEND or PDEPEND - in fact, I saw someone asking for help for ages in #gentoo-dev-help on freenode, without getting an answer about a circular dep... they just needed to use PDEPEND. (Hardly anyone knows about it... )

Why couldn't this be handled by a generator?

Anyway, this discussion is going a bit in circles and although I like the idea I won't be the only one to support it. I'll get out of this discussion now and wait for other supporters. If there are no other supporters then I guess the GUI ebuild generator isn't a good idea anyway and should fade away to the realm of a nice fantasy.
So other supports, please get active now.

Anyway, this discussion is going a bit in circles and although I like the idea I won't be the only one to support it. I'll get out of this discussion now and wait for other supporters.

And I will do the same.

Q-collective wrote:

So other supports, please get active now.

If you people really do exist.

One last note, although I already stated this a while back: I don't think a generator this smart will ever be created (calculate dependencies, know which eclasses to use, know how to manually install files when there is no make install, etc.). And, hypothetically speaking, if it was to be created, it would take much more development to design and keep up-to-date such a generator than to maintain a bunch of extra ebuilds.

[edit] Also interesting how the idea went from simple dialog boxes for choosing dependencies to something that does all the work. _________________meow.

Guys, I suggest you stopped arguing wether DreamWeaver is good or bad; if you wanted a DreamWeaver discussion, better create a dedicated thread .

My idea is as follows: if the principles of an ebuild can be described in some clearly understandable language, then they can be modelized. If they can be modelized, then they should be coded.

Given the complexity of an ebuild - hence the numerous potential sources of errors, we're all humans - an automated way of generating ebuilds is a plus, of course. No doubt there *are* advantages.

No-one said that such a tooll would be the only way to generate an ebuild. And no-one mentionned there should be no other way to create one. Many generators allow for customizing (e.g. by hand).

No-one said an ebuild generator is an easy task. There are tools to generate makefiles; why not for ebuilds? (I'm not saying creating a makefile is easier than creating an ebuild nor did I say creating a tool to create makefiles is easier than creating a tool to create ebuilds... Follow me? )

Such a tool seems challenging. So go for it, don't you?

Aaaaaand if creating such a tool is really, really, really much too complex then maybe portage itself has become far too complex? Anyway it's time the question was asked._________________Dealing with computers is searching for troubles, which refraining from touching them in the first place would have spared you from!Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...

Given the complexity of an ebuild - hence the numerous potential sources of errors, we're all humans - an automated way of generating ebuilds is a plus, of course. No doubt there *are* advantages.

The reason why there are errors is because of very complex code in the ebuild - would anyone be able to write a program that can automagically come up with all this complex code? I think not... I think some kinda program which you could write ebuilds in, with syntax highlighting and so on and so forth would be rather nice... oh! wait a minute!, vim already does that - I don't think anyone wants to reinvent the wheel, do they? _________________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

The reason why there are errors is because of very complex code in the ebuild - would anyone be able to write a program that can automagically come up with all this complex code? I think not...

Take a CRM or an ERP for instance. It involves very complex code. And people succeeded in acheiving such a complex task.

The level of complexity is not IMHO a reason *not* to create applications. Otherwise we would still use a hammer and a marble tablet..._________________Dealing with computers is searching for troubles, which refraining from touching them in the first place would have spared you from!Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...

Tell you what, go read through the whole of devmanual.gentoo.org, and then tell me if you still think you can write a GUI for building ebuilds. And go take a look at some of the more advanced ebuilds, such as the ones for mozilla, openoffice and so on..._________________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

would anyone be able to write a program that can automagically come up with all this complex code? I think not... I think some kinda program which you could write ebuilds in, with syntax highlighting and so on and so forth would be rather nice... oh! wait a minute!, vim already does that - I don't think anyone wants to reinvent the wheel, do they?

(And speaking about other things said in this whole thread) How do you know? Saying that "no one can" before someone has attempted it is a bad argument. Sorry to be rude, but I really hate arguments that are like that. You are trying to argue the future, which is impossible. There were nay-sayers that said that the sound barrier could not be broken -- it was broken. There were people saying that no one would be able to walk on the moon -- we walked on the moon more than one time. There are people saying that writing a program to handle the complex structure of the ebuilds -- we don't know for sure until someone tries.

My suggestion is that someone should just write the thing. If it works, it works, if it don't it don't. Either way, someone will be proved wrong and someone will be proved right. If no one did anything because there were a few nay-sayers, then we would have never walked on the moon and the sound barrier would have never been broken. Another words, if you want to do something, do it, but you are not going to get anywhere by arguing about if it can be done or not. If you want to tackle this issue and write a GUI, then write it. Remember, you will never satisfy everyone. There will always be someone against something or for something no matter what arguments are out there to either prove or disprove said something.

I am not going to say that this program can be written or not -- I don't know if it can, but can I say it's impossible because I lack the knowledge to write such a program? No, I can not. To say something can't be done only means that one lacks the knowledge to solve the problem. And if people don't like the idea to begin with ... well ... they don't like it. For example: There are some that love Genkernel and there are some that don't like it and yet Genkernel is developed and used. This will always be the same with this "GUI for ebuilds" idea, like so many other wars like the nano/emacs/vi war. There are just too many wars in the Linux world. Just give it a rest. This will never be settled. If you don't like the idea of the GUI, then just don't fight, if like like the idea of the GUI, then plan it out. It's as simple as that._________________Nothing to read in this sig. Move along.

I agree 100% on your principles, StifflerStealth._________________Dealing with computers is searching for troubles, which refraining from touching them in the first place would have spared you from!Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...

So I guess things like visual basic defy some law of the universe since you are able to create complex applications without nessecarily having to dick around with 1000000000000000000000000000 lines of code that have to do with generating the overal visual functionality of a given program leaving the developer free to concentrate on making the pretty windows do something.................I say go for it I might actually take the time to write some basic ebuilds if I had something like that available to me; as it is now I can't be arsed to go and learn yet another language from the ground up on top of trying to learn more VB and get better aquainted with Ruby. I would welcome a tool that presented a sort of fill in the blank type of interface that let me type in various types of info and presented me with buttons for other options got an ebuild going and then if I noticed a problem allowed me to go into the guts and deal with it directly._________________Ware wa mutekinari.
Wa ga kage waza ni kanau mono nashi.
Wa ga ichigeki wa mutekinari.

"First there was nothing, so the lord gave us light. There was still nothing, but at least you could see it."

I'm going to make a GUI for creating compilers. It will make much better compilers than are currently available by removing the human error factor, and will be greatly beneficial to the community because then anyone would be able to write their own language and have a compiler without needing to learn all the nitty gritty about how they work.

I'm going to make a GUI for creating compilers. It will make much better compilers than are currently available by removing the human error factor, and will be greatly beneficial to the community because then anyone would be able to write their own language and have a compiler without needing to learn all the nitty gritty about how they work.

I'm going to make a GUI for creating compilers. It will make much better compilers than are currently available by removing the human error factor, and will be greatly beneficial to the community because then anyone would be able to write their own language and have a compiler without needing to learn all the nitty gritty about how they work.

So basically, you, devs, do not want to make a GUI for creating ebuilds because you are afraid that we, compiler dummies, spoil your reputation of developers...

Hmmm... closed-source companies didn't want their precious software to be stolen by anyone either. The result was... Open Source software.

Open Developers, anyone? _________________Dealing with computers is searching for troubles, which refraining from touching them in the first place would have spared you from!Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...

I'm going to make a GUI for creating compilers. It will make much better compilers than are currently available by removing the human error factor, and will be greatly beneficial to the community because then anyone would be able to write their own language and have a compiler without needing to learn all the nitty gritty about how they work.

So basically, you, devs, do not want to make a GUI for creating ebuilds because you are afraid that we, compiler dummies, spoil your reputation of developers...

Hmmm... closed-source companies didn't want their precious software to be stolen by anyone either. The result was... Open Source software.

Open Developers, anyone?

Yes, it's a very elitaristic attitude.
And we all hate Debian for their "elitist bastard" culture, right?

Unless someone writes a unified system for building packages and patch the existing software to work with it, the whole idea is doomed...
There is so much to compansate in such "omnipotent" ebuild writer for the things, which are simply broken and for the diversity of build systems used in the software, that it is an essentially impossible task..._________________"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack

So basically, you, devs, do not want to make a GUI for creating ebuilds because you are afraid that we, compiler dummies, spoil your reputation of developers...

No, I was attempting to illustrate that ebuilds are far too complex to express in an even remotely usable GUI, and that if you're going to create the things then you really should know how they work. Apparently it went right over everyone's heads, though, so I'll remember to dumb it down in future.