Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 489232

Summary: net-misc/ttytter - add readline support
Product: Gentoo Linux Reporter: Peter Gantner (a.k.a. nephros) <gentoo>
Component: Current packagesAssignee: No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed>
Status: UNCONFIRMED ---    
Severity: enhancement    
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on: 489540    
Bug Blocks:    
Attachments: ttytter-2.1.00.ebuild
Term-ReadLine-TTYtter-1.4.ebuild

Description Peter Gantner (a.k.a. nephros) 2013-10-24 06:42:24 UTC
net-misc/ttytter supports readline editing, however it needs a perl implementation for readline to be available.

As mentioned in its FAQ (http://www.floodgap.com/software/ttytter/dl.html) per default it looks for Term::ReadLine::TTYtter but there is no ebuild for that.

It can also support either dev-perl/Term-ReadLine-Gnu or dev-perl/Term-ReadLine-Perl through setting an environment variable beforehand.

I suggest adding a readline USE flag to net-misc/ttytter and letting that depend on either of the three implementations.

An ebuild for Term::ReadLine::TTYtter would have to be created first.
Comment 1 Peter Gantner (a.k.a. nephros) 2013-10-24 06:43:56 UTC
Forgot to mention, in the state net-misc/ttytter is installed right now, it can only fallback to non-readline mode (Term::ReadLine::Stub), making it much less convenient to use.
Comment 2 Peter Gantner (a.k.a. nephros) 2013-10-24 11:42:54 UTC
Created attachment 361780 [details]
ttytter-2.1.00.ebuild

ttytter ebuild with readline support and the three perl dependencies added
Comment 3 Peter Gantner (a.k.a. nephros) 2013-10-24 11:44:10 UTC
Created attachment 361782 [details]
Term-ReadLine-TTYtter-1.4.ebuild

dev-perl/Term-ReadLine-TTYtter-1.4 ebuild

should have its own bug but attaching here for the moment in case someone wants to test this.
Comment 4 Jeroen Roovers (RETIRED) gentoo-dev 2013-10-24 14:40:03 UTC
Comment on attachment 361780 [details]
ttytter-2.1.00.ebuild

--- ttytter-2.1.00.ebuild       2013-09-15 16:16:19.419496810 +0200
+++ -   2013-10-24 16:39:33.922289513 +0200
@@ -13,10 +13,17 @@
 LICENSE="FFSL"
 SLOT="0"
 KEYWORDS="amd64 x86"
-IUSE=""
+IUSE="readline"
 DEPEND=""
 RDEPEND=">=dev-lang/perl-5.8
-       || ( net-misc/curl www-client/lynx )"
+       || ( net-misc/curl www-client/lynx )
+       readline? (
+               || (
+                       dev-perl/Term-ReadLine-TTYtter
+                       dev-perl/Term-ReadLine-Gnu
+                       dev-perl/Term-ReadLine-Perl
+               )
+       )"
 
 pkg_setup() {
        DOC_CONTENTS="Please consult the following webpage on how to
@@ -34,3 +41,17 @@
        dobin ${PN}
        readme.gentoo_create_doc
 }
+
+pkg_postinst() {
+       if use readline; then
+               einfo "You have the 'readline' USE flag set."
+               einfo ""
+               einfo "Per default ttytter will use Term::ReadLine::TTYtter as"
+               einfo "its readline implementation (if installed)."
+               einfo "You can switch to either Term::ReadLine::Gnu or Term::ReadLine::Perl"
+               einfo "by setting the environment variable PERL_RL to either \"Gnu\" or"
+               einfo "\"Perl\", respectively."
+               einfo ""
+               einfo "See http://www.floodgap.com/software/ttytter/dl.html for more information."
+       fi
+       }
Comment 5 Markos Chandras (RETIRED) gentoo-dev 2013-10-26 14:14:54 UTC
(In reply to Peter Gantner (a.k.a. nephros) from comment #3)
> Created attachment 361782 [details]
> Term-ReadLine-TTYtter-1.4.ebuild
> 
> dev-perl/Term-ReadLine-TTYtter-1.4 ebuild
> 
> should have its own bug but attaching here for the moment in case someone
> wants to test this.

This package needs to be on a separate bug and have the perl team or proxy-maintainers to take care of it. Could you please open a new bug instead? It makes it really hard to track two packages in a single bug
Comment 6 Peter Gantner (a.k.a. nephros) 2013-10-27 08:43:31 UTC
created #489540 for the perl ebuild as requested
Comment 7 Markos Chandras (RETIRED) gentoo-dev 2013-11-06 17:46:18 UTC
useflags in RDEPEND should be avoided because the package does not change whether  this flag is enabled or not. Would it be a problem to add the required packages in the pkg_postinst message and inform the user to merge them if he/she needs readline support?
Comment 8 Peter Gantner (a.k.a. nephros) 2013-11-06 18:48:52 UTC
(In reply to Markos Chandras from comment #7)
> useflags in RDEPEND should be avoided because the package does not change
> whether  this flag is enabled or not.

Well in this specific case this is true: the installation will look exactly the same with the use flag or without it.
The program will at runtime pull in an installed perl readline implementation, and if it doesn't find one fallback to non-readline mode.

> Would it be a problem to add the
> required packages in the pkg_postinst message and inform the user to merge
> them if he/she needs readline support?

Not a problem at all, technically. I don't like it though:

1. I feel though that packages with elog messages should be kept to a minimum. It's just not fun to scour through all the elogs after a bigger emerge for things like this.

2. If there is a readline USE flag and I as a user have it enabled, I expect to enable readline support in the resulting installation. Why would it require me to manually install dependencies afterwards? I have already stated I want that support in my USE flags.

OTOH in the current way where there is no support, the package "hides" useful features from me, will always start in degraded mode.


But that really is just my opinion as a user. If doing it the way you propose is the preferred way I'll be happy to do the changes.
Comment 9 Markos Chandras (RETIRED) gentoo-dev 2013-11-06 20:01:20 UTC
(In reply to Peter Gantner (a.k.a. nephros) from comment #8)
> 
> Not a problem at all, technically. I don't like it though:
> 
> 1. I feel though that packages with elog messages should be kept to a
> minimum. It's just not fun to scour through all the elogs after a bigger
> emerge for things like this.

Indeed but this is the recommended way for optional runtime-only dependencies.

> 
> 2. If there is a readline USE flag and I as a user have it enabled, I expect
> to enable readline support in the resulting installation. Why would it
> require me to manually install dependencies afterwards? I have already
> stated I want that support in my USE flags.

Maybe pull the readline use flags unconditionally then? It's just three packages. But I still prefer the user to do it manually. And users are expected to read the elog messages. We have them there for a reason.

> 
> But that really is just my opinion as a user. If doing it the way you
> propose is the preferred way I'll be happy to do the changes.

If are ok with it, could you submit a new ebuild listing the optional runtime dependencies in the postinst function? Then I will commit it asap!