IO::Stty module is used at line 396 in the function exp_stty()
Created attachment 262999 [details] IO-Stty-0.03.ebuild Proposed ebuild
Created attachment 263001 [details] IO-Stty-0.03.ebuild fixed the license
IO-Stty is an optional dependency of Expect. If pacmanager uses IO::Stty, it probably should depend on it itself.
You're right, IO::Stty is only optional for Expect but at the end IO::Stty is used directly by Expect while pacmanager is using directly Expect (in particular the interact() function which needs Expect with IO::Stty). So I'm little bit confused on which is the right approach to express the dependencies. Tell me in which way to proceed, I can add another dependency to pacmanager if needed.
Mikle, can you explain why is obsolete?
I'm still facing this bug, here is the code if Expect.pm: sub exp_stty { my($self) = shift; my($mode) = "@_"; return undef unless defined($mode); if (not defined $INC{"IO/Stty.pm"}) { carp "IO::Stty not installed, cannot change mode"; return undef; } if (${*$self}{"exp_Debug"}) { print STDERR "Setting ${*$self}{exp_Pty_Handle} to tty mode '$mode'\r\n"; } unless (POSIX::isatty($self)) { if (${*$self}{"exp_Debug"} or $^W) { warn "${*$self}{exp_Pty_Handle} is not a tty. Not changing mode"; } return ''; # No undef to avoid warnings elsewhere. } IO::Stty::stty($self, split(/\s/,$mode)); } As you can see the IO/Stty.pm module is used in the function exp_stty()
I see that IO/Stty.pm is only optionally used but the user has no option to enable/disable it from Expect ebuild and doesn't know it can be exploited by the Expect package so he/she can experience a miss of functionality. For this reason I have just reopened this bug report
1. There's no simple way to "disable" this behaviour, only expose that it is there as a USE dependency. 2. What would you describe you are doing with Expect when you are encountering this issue ( I'm trying to find a good name for a USE flag but I'm short of ideas ) If no better suggestions are forthcoming, I'll just make a "minimal" USE flag, and pull IO::Stty by default *unless* that flag is set.
(In reply to Kent Fredric from comment #8) > If no better suggestions are forthcoming, I'll just make a "minimal" USE > flag, and pull IO::Stty by default *unless* that flag is set. I like this solution, the IO::Stty is very small so I guess it can be always pulled in.
Ugh. I overlooked that Stty is in the overlay, but Expect is main tree. K.
https://github.com/gentoo/gentoo/pull/135
dev-perl/Expect picked up a new dependency. Arches please keyword, target ~arm ~ppc ~ppc64 ~sparc dev-perl/Expect-1.320.0-r1 dev-perl/IO-Stty (In reply to Kent Fredric from comment #11) > https://github.com/gentoo/gentoo/pull/135 Merged.
(In reply to Andreas K. Hüttel from comment #12) > dev-perl/Expect picked up a new dependency. > Arches please keyword, target > ~arm ~ppc ~ppc64 ~sparc > > dev-perl/Expect-1.320.0-r1 > dev-perl/IO-Stty > > > > > (In reply to Kent Fredric from comment #11) > > https://github.com/gentoo/gentoo/pull/135 > Merged. Thanks for the addition. I have noticed that the IO-Stty version encoded in the ebuild name is wrong (the perl package version is 0.03 while the ebuild name uses 0.30.0, I guess it should be 0.03.0)
(In reply to Fabio Rossi from comment #13) > Thanks for the addition. I have noticed that the IO-Stty version encoded in > the ebuild name is wrong (the perl package version is 0.03 while the ebuild > name uses 0.30.0, I guess it should be 0.03.0) Perl herd normalises CPAN versions to a consistent scheme due to the incompatibility of Perl version schemes with ours. Upstream 0.03 is upstream 0.030 is upstream 0.030000 The version is correct *inside* the ebuild however: MODULE_VERSION=0.03 And we use dev-perl/Gentoo-PerlMod-Version standard-issue for normalising both versions in packages themselves, and versions in dependencies, to minimise unexpected side effects ( especially when upstream change versioning schemes ) gentoo-perlmod-version.pl 0.03 0.03 => 0.30.0 More details can be read about here: https://metacpan.org/pod/Gentoo::PerlMod::Version#DESCRIPTION ( There are some inaccuracies there still I have to correct, but the general motivation is still true )
I didn't know that, thanks for the explanation!
Marked ~ppc64.
Keyworded for ppc.
This request is almost 4 years old (!). I'd gladly go ahead and keyword the two remaining arches if you guys aren't able to do so.
~arm done
~sparc done
