yeahconsole ebuild anyone?

[krolden]

Tilda is going to be removed out of portage and kuake is qt, so I thought why not switch to yeahconsole.

http://freshmeat.net/projects/yeahconsole/

[SoTired]

Does http://forums.gentoo.org/viewtopic-p-24 ... ml#2423197 no longer work?

[Dlareh]

For crying out loud, how is an ebuild simpler than dumping the tarball somewhere and:

Code: Select all

./autogen.sh
./configure
make && make install

?

If yeahconsole were in portage, then, yes, "emerge yeahconsole" would be nice. But when you have to stick an ebuild in an overlay and digest it... for such a simple program, manual installation is EASIER, and far less prone to unmaintained ebuild hiccups.

InfinityX's no delay patch is great; use it.

[SoTired]

For crying out loud, how is an ebuild simpler than dumping the tarball somewhere and:

Code: Select all

./autogen.sh
./configure
make && make install

?

With portage you're guaranteed that the files during the 'make install' stage will go where you expect them to. Without portage you might have to pass some arguments to configure. Following from the latter point, uninstall is also automatic.

If yeahconsole were in portage, then, yes, "emerge yeahconsole" would be nice. But when you have to stick an ebuild in an overlay and digest it... for such a simple program, manual installation is EASIER, and far less prone to unmaintained ebuild hiccups.

It's really a few trivial commands either way. And seeing as yeahconsole hasn't been updated in almost a year there probably won't be too many problems with unmaintained ebuilds for it.

[Dlareh]

With portage you're guaranteed that the files during the 'make install' stage will go where you expect them to. Without portage you might have to pass some arguments to configure. Following from the latter point, uninstall is also automatic.

File, singular. /usr/local/bin/yeahconsole

If yeahconsole were in portage, then, yes, "emerge yeahconsole" would be nice. But when you have to stick an ebuild in an overlay and digest it... for such a simple program, manual installation is EASIER, and far less prone to unmaintained ebuild hiccups.

It's really a few trivial commands either way.

No, copy pasting an ebuild, putting it into an overlay, digesting, and finally emerging the package is much more complex than copy pasting a handful of commands into any root terminal, is more prone to failure, and offers zero benefits.

And seeing as yeahconsole hasn't been updated in almost a year there probably won't be too many problems with unmaintained ebuilds for it.

My objection to unmaintained ebuilds has nothing to do with whether new versions of yeahconsole are released.

The ONLY reason developing a yeahconsole ebuild would have been worthwhile is if there were any reason to put it in the Gentoo portage tree. There isn't, so it's useless.

[SoTired]

File, singular. /usr/local/bin/yeahconsole

Just an example, many packages will install man pages et cetera.

If yeahconsole were in portage, then, yes, "emerge yeahconsole" would be nice. But when you have to stick an ebuild in an overlay and digest it... for such a simple program, manual installation is EASIER, and far less prone to unmaintained ebuild hiccups.

It's a few trivial commands/mouse clicks either way.

No, copy pasting an ebuild, putting it into an overlay, digesting, and finally emerging the package is much more complex than copy pasting a handful of commands into any root terminal...

They are both utterly trivial.

...is more prone to failure...

And will in fact work if the package needs a more complex install than ./configure && make && make install, provided that the ebuild provides for this.

...and offers zero benefits.

Automatic uninstall, correct locating of all files, usage of portage variables, possibility of use flags - the list could go on.

My objection to unmaintained ebuilds has nothing to do with whether new versions of yeahconsole are released.

Okay, than it is a groundless objection in this case. In the general case I have a number of ebuilds in my overlay that aren't in portage, all of which are up to date. Should any fall out of date it's generally not too difficult for the user to go in and update them themself, or to look on these forums for an updated version.

The ONLY reason developing a yeahconsole ebuild would have been worthwhile is if there were any reason to put it in the Gentoo portage tree. There isn't, so it's useless.

Other reasons for an ebuild: Because doing so is trivial. Because many people like using ebuilds for as many packages as possible. Use flags et al.
Reasons for an ebuild in portage: So people who do not read the forums can search for it. So people who aren't comfortable compiling their programs by hand can get it easily. Because that is the entire purpose of portage - it's not just there for the complex things.


I'll being so offtopic now.

[Dlareh]

File, singular. /usr/local/bin/yeahconsole

Just an example, many packages will install man pages et cetera.

We were discussing yeahconsole. If you wish to discuss other things instead, please stop wasting my time.

It's a few trivial commands/mouse clicks either way.

They are both utterly trivial.

One can be done in seconds, the other requires having a properly set up overlay and a lot of manual typing. The ratio of complexity is.... 50:1 (to pull a ballpark figure out of my ass)

...is more prone to failure...

And will in fact work if the package needs a more complex install than ./configure && make && make install, provided that the ebuild provides for this.

Irrelevant to the type of failures I am talking about. Unmaintained, untested ebuilds fail much more often than simple code listings.

...and offers zero benefits.

Automatic uninstall, correct locating of all files, usage of portage variables, possibility of use flags - the list could go on.

Irrelevant to yeahconsole.

My objection to unmaintained ebuilds has nothing to do with whether new versions of yeahconsole are released.

Okay, than it is a groundless objection in this case.

No it is not, for the simple reason mentioned above.

In the general case I have a number of ebuilds in my overlay that aren't in portage, all of which are up to date.

Are they sufficiently complex pieces of software for which an ebuild is actually useful?

I'll ignore the rest of your post since none of it is relevant.

[aaronf0]

hrm, lets send some people through portage and delete all the crpa that is useless in there. we can start with the kernel builds, all they do is download the source, and some patch files. trivial by hand. now, how about xorg? other than the patches, its a simple install, just a make && make install. now we can also get rid of most of the crap in portage, cept a few things that are rather complicated to do by hand. so WHY THE FUCK PUT ANY PACKAGES IN PORTAGE AT ALL?

[citizen428]

Although I completely agree with Dlareh in this case, I've done an ebuild for yeahconsole, which also includes the patch by InfinityX.

http://dev.gentoo.org/~citizen428/files ... le.tar.bz2

The tarball contains the entire directory including Manifest and digests, which means you only have to unpack it in your portage overlay.

Note: I surely won't add this to our tree, as I think it's not worth it. I've only done this ebuild because people have requested it on several occasions.

[kungfooguru]

Just making sure people arn't judging tilda based on what is in portage. That is very old an a POS. Check out tilda.sf.net to see how it looks now and maybe give it a try. The ebuilds for all the new versions are in bugzilla as well. Tilda has even been excepted into Ubuntu Breezy Badger's universal repository.

Tristan

[psycepa]

Just making sure people arn't judging tilda based on what is in portage. That is very old an a POS. Check out tilda.sf.net to see how it looks now and maybe give it a try. The ebuilds for all the new versions are in bugzilla as well. Tilda has even been excepted into Ubuntu Breezy Badger's universal repository.

Tristan

kungfooguru, tell me honestly, in your objective opinnion: tilda is better than yeahconsole or is it just the opposite ?