Ebuild GUI or ! Ebuild GUI
Well, after reading all this I totally agree with Q-Collective: its going circles.
Before I start, I have to mention few things:
1. This issue cannot be resolved in one forum thread. It is too controversial for some people, and as such, there always will be someone with "I have to say the last word!!!" attitude.
2. It is obvious, that a stance on this is different for developers and users. Hence, it has to be dealt with each group accordingly.
3. I never (or almost never) take one side in the argument. That is probably because I still haven't been in an argument that I 100% agree with.
Now to the point.
As I understand, the major question is whether there should be a tool for automatic building of ebuilds. There are 2 major opinions:
USERS: of course!!!! For ages I've been secretly dreaming to write lots of ebuilds, sometimes even a couple before I go to sleep/lunch/out ( Choose appropriate, - Alex), but those evil developers made it so complicated, that ordinary humans cannot master the craft. And that documentation thing? One has to read it to be able to do anything.....its awful.
DEVS: nonsense!!!! Noone in his healthy mind would need such a thing. We wouldn't want to bring piles of users (read crappy, - A.) ebuilds in, and we would not like to maintain those, and we wouldn't like to develop yet another portage application. Besides, it would be too complex to be somewhat useful, and totally useless if made for simple things.
Other opinions, simply put in terms of quantum mechanics, are superposition of these two.
Now I would like to analize the problem in hand, what it is good for and why would it help (or not).
I start with the basics: do we need an Automatic/GUI/Text/Whatever ebuild builder (TM) ?Before I start, I have to mention few things:
1. This issue cannot be resolved in one forum thread. It is too controversial for some people, and as such, there always will be someone with "I have to say the last word!!!" attitude.
2. It is obvious, that a stance on this is different for developers and users. Hence, it has to be dealt with each group accordingly.
3. I never (or almost never) take one side in the argument. That is probably because I still haven't been in an argument that I 100% agree with.
Now to the point.
As I understand, the major question is whether there should be a tool for automatic building of ebuilds. There are 2 major opinions:
USERS: of course!!!! For ages I've been secretly dreaming to write lots of ebuilds, sometimes even a couple before I go to sleep/lunch/out ( Choose appropriate, - Alex), but those evil developers made it so complicated, that ordinary humans cannot master the craft. And that documentation thing? One has to read it to be able to do anything.....its awful.
DEVS: nonsense!!!! Noone in his healthy mind would need such a thing. We wouldn't want to bring piles of users (read crappy, - A.) ebuilds in, and we would not like to maintain those, and we wouldn't like to develop yet another portage application. Besides, it would be too complex to be somewhat useful, and totally useless if made for simple things.
Other opinions, simply put in terms of quantum mechanics, are superposition of these two.
Now I would like to analize the problem in hand, what it is good for and why would it help (or not).
For some reason, the question, albeit simple, got complicated in the way. I think this might be easier if we dissect it a little bit, such as:
1. What would such a tool provide and how can it help?
2. What sorts (kinds, types, etc) of ebuilds we would like to be able to create with such a thing?
Starting with first part, what would such tool do for me? Quoting Q-Collective, "it will help to make the tree bigger". Regargind this remark - as I know based on my own humble opinion, the most frequent type of package any "normal" user would like to add, can be compiled with simple "./configure; make; make install". Now, that, is what I would call the default ebuild for a package. What would be needed for generation of an ebuild for that? Just URL for source files and description. Is it that hard to do? Don't implement USE, DEPEND and RDEPEND. Just default 3 commands.
Now, to prove the point, take that "normal" user and ask her to write an ebuild manually. That would be funny.
So, going to second part, if we can identify at least one type of ebuilds that can be created with such a tool, can we find more? And if we cannot, would one small type thing matter anything?
As for other types of ebuilds with one simple "builder" - I really doubt it. Not because I think its impossible, but because, no matter how loud "normal" users would cry about creating ebuilds, one should understand the process, meaning that if default ebuild doesn't work, then probably the whole thing is sorta pointless, because there are not so much users who would even test the package installation with default 3 commands in the first place. A user, should she decide to create an ebuild, and given that default one doesn't work, should be able to understand why it doesn't work, and not just play american tests with some GUI (or text, doesn't matter) wizard.
Now, regadring "crappy" packages. If the tool created by someone, who deliberately thought out the way it should work, then please, with all do respect, define a "crappy" to me. And how can default ebuild be crappy if all it does is to run make? That does not make any sense to me.
What does though, that if lot of users were to use such tool, then devs would get consistent, streamlined and understandably written ebuilds, and not a mesh-up created by hourdes of different people, each with her own style of coding.
Now, as I partially done with users, lets see what it holds for developers.
1. If such a tool was to exist, and users would start to use it and donate ebuilds, would it contribute something? Absolutely. First, you could ignore it, and then nothing is changed if compared with what we have today, and you still have users who do not really involved with the distro, although they might want to. Second, you would get loads (supposedly) of ebuilds, all written the same way, easy to understand for you. Maybe it would be good enough to put it in overlay or even tree - but then, you get in effect, user-contributed content, which holds two-fold advantage: you work less, because all you did is check that ebuild is ok (not essentially getting to know the software), and also user feels like she did something.
2. It might incite user to solve the problem if default ebuild didn't work, thus making the user more proficient in ways of portage, and in effect making a user more valuable contributor.
3. If a package is inserted to Bugzilla, wouldn't you prefer some more controlled way that users would go when creating packages? Noone would argue that creating packages with automatic process is much better that user who really doesn't know portage writes one and submits it.
So, to sum up, here my conclusions:
Q1. It seems to be, that only for default process of installing a software an ebuild can be automatically and correctly created. Does this worth the effort of creating another "software" and inserting more bugs into what we have?
A1. Absolutely!!! I do think, that by providing a way to create such default ebuild (and maybe even placing it automatically in overlay area on the machine would be great, and submitting to bugzilla automatically from the same script given username and password would be even better), it would create a lot of opportunities for users to contribute new packages. I know from my own expirience, that I gave up on creating few ebuilds just because each time I wanted to do that, I lost myself in documentation on one step or the other, and too much time was spent on seemingly simple things. I shouldn't spent my time looking for right versioning scheme, which can change rapidly.
Q2. Wait, you're saying that this thing should do one type of ebuilds only??? Are you nuts?
A2. No, its not what I said. This app can do one type only at the beginning, and if wanted it can be easily expanded. I beleive, that writing one simple "builder" for one type of ebuild, can be done by proficient portage programmer in 15 minutes, and then GUI can be added to it by some more artistic person in another 15 minutes. No need to dramatize.
Q3. OK, but what do we do with those ebuilds??
A3. The same thing that done today with ebuilds submitted to Bugzilla.
And the last thing.
As it seems, such a tool mainly would support users (read one-time contributors) and help them to get involved. It would not enforce developers to action, nor would promise users their ebuilds will be taken. It is just a tool, its purpose it to help make things happen, not to make things happen.
And for developers, I do beleive that creating an IDE may help a lot, meaning function checks, test, cross-referencing between classes, inline help, etc. And building it upon Eclipse seems to me good idea
And a really last thing. I still hope, that even given this tool comes to life, I hope that mentoring will still require knowledge of how to use text editor to create ebuilds. Not some fancy shmancy builder.
As always, just my humble opinion. Comments are welcome even on this one.
1. What would such a tool provide and how can it help?
2. What sorts (kinds, types, etc) of ebuilds we would like to be able to create with such a thing?
Starting with first part, what would such tool do for me? Quoting Q-Collective, "it will help to make the tree bigger". Regargind this remark - as I know based on my own humble opinion, the most frequent type of package any "normal" user would like to add, can be compiled with simple "./configure; make; make install". Now, that, is what I would call the default ebuild for a package. What would be needed for generation of an ebuild for that? Just URL for source files and description. Is it that hard to do? Don't implement USE, DEPEND and RDEPEND. Just default 3 commands.
Now, to prove the point, take that "normal" user and ask her to write an ebuild manually. That would be funny.
So, going to second part, if we can identify at least one type of ebuilds that can be created with such a tool, can we find more? And if we cannot, would one small type thing matter anything?
As for other types of ebuilds with one simple "builder" - I really doubt it. Not because I think its impossible, but because, no matter how loud "normal" users would cry about creating ebuilds, one should understand the process, meaning that if default ebuild doesn't work, then probably the whole thing is sorta pointless, because there are not so much users who would even test the package installation with default 3 commands in the first place. A user, should she decide to create an ebuild, and given that default one doesn't work, should be able to understand why it doesn't work, and not just play american tests with some GUI (or text, doesn't matter) wizard.
Now, regadring "crappy" packages. If the tool created by someone, who deliberately thought out the way it should work, then please, with all do respect, define a "crappy" to me. And how can default ebuild be crappy if all it does is to run make? That does not make any sense to me.
What does though, that if lot of users were to use such tool, then devs would get consistent, streamlined and understandably written ebuilds, and not a mesh-up created by hourdes of different people, each with her own style of coding.
Now, as I partially done with users, lets see what it holds for developers.
1. If such a tool was to exist, and users would start to use it and donate ebuilds, would it contribute something? Absolutely. First, you could ignore it, and then nothing is changed if compared with what we have today, and you still have users who do not really involved with the distro, although they might want to. Second, you would get loads (supposedly) of ebuilds, all written the same way, easy to understand for you. Maybe it would be good enough to put it in overlay or even tree - but then, you get in effect, user-contributed content, which holds two-fold advantage: you work less, because all you did is check that ebuild is ok (not essentially getting to know the software), and also user feels like she did something.
2. It might incite user to solve the problem if default ebuild didn't work, thus making the user more proficient in ways of portage, and in effect making a user more valuable contributor.
3. If a package is inserted to Bugzilla, wouldn't you prefer some more controlled way that users would go when creating packages? Noone would argue that creating packages with automatic process is much better that user who really doesn't know portage writes one and submits it.
So, to sum up, here my conclusions:
Q1. It seems to be, that only for default process of installing a software an ebuild can be automatically and correctly created. Does this worth the effort of creating another "software" and inserting more bugs into what we have?
A1. Absolutely!!! I do think, that by providing a way to create such default ebuild (and maybe even placing it automatically in overlay area on the machine would be great, and submitting to bugzilla automatically from the same script given username and password would be even better), it would create a lot of opportunities for users to contribute new packages. I know from my own expirience, that I gave up on creating few ebuilds just because each time I wanted to do that, I lost myself in documentation on one step or the other, and too much time was spent on seemingly simple things. I shouldn't spent my time looking for right versioning scheme, which can change rapidly.
Q2. Wait, you're saying that this thing should do one type of ebuilds only??? Are you nuts?
A2. No, its not what I said. This app can do one type only at the beginning, and if wanted it can be easily expanded. I beleive, that writing one simple "builder" for one type of ebuild, can be done by proficient portage programmer in 15 minutes, and then GUI can be added to it by some more artistic person in another 15 minutes. No need to dramatize.
Q3. OK, but what do we do with those ebuilds??
A3. The same thing that done today with ebuilds submitted to Bugzilla.
And the last thing.
As it seems, such a tool mainly would support users (read one-time contributors) and help them to get involved. It would not enforce developers to action, nor would promise users their ebuilds will be taken. It is just a tool, its purpose it to help make things happen, not to make things happen.
And for developers, I do beleive that creating an IDE may help a lot, meaning function checks, test, cross-referencing between classes, inline help, etc. And building it upon Eclipse seems to me good idea
And a really last thing. I still hope, that even given this tool comes to life, I hope that mentoring will still require knowledge of how to use text editor to create ebuilds. Not some fancy shmancy builder.
As always, just my humble opinion. Comments are welcome even on this one.
2 comments:
I've had to install a few tools the old/manual way and would have been able to provide a few "simple ebuilds" like you suggest.
I think the biggest problem is that it's technically not really feasible to account for every possible scenario that an ebuild needs, which is why you can't create more than "simple" ebuilds which really doesn't then solve the problem of why people want one in the first place.
The idea of just having it run ./configure, make and make install by default with no USE flag options is a good one. The only problem though is it will do stuff like notice you have perl installed and install perl dependencies by default. But if you change your perl deps around, this one would / could suddenly break. If you packed in an option to disable perl support, that wouldn't be a problem.
Anyway -- if the entry level to creating ebuilds is too steep a curve then *that* should be addressed through documentation. Creating a *simple* ebuild is easy, yes, but there are a lot where a simple ebuild formula just isn't going to work, and it's going to take some amount of sweat and tears to figure it out.
Besides, I would encourage users to learn how to write ebuilds. We could use more developers. :)
Post a Comment