Bugzilla Bug 126409

liljencrantz Freso: Fish internally uses the 'xsel' command to synchronize with
the X clipboard for copy-and-paste
Freso Yes?
liljencrantz Freso: Because of this, fish is acutally shipped with the source
code for xsel
Freso Ah.
liljencrantz Freso: But it is really a different project
liljencrantz Freso: So the _proper_ thing to do would be to split out xsel
Freso Yes.
liljencrantz Freso: And add a use flag for xsel to fish
Freso Or just add xsel as a dependency. :)
liljencrantz Freso: I belive this is what jamessan does with the debian package
Freso Depends on how core you think it is.
liljencrantz Freso: Fish will work just fine without xsel, but you get no X
copy-and-paste suppor. Fish will simply ise an internal clipboard instead
jamessan liljencrantz: if --without-xsel is used, but xsel is installed
independently, would fish still use xsel?
Freso liljencrantz: Right. I don't use fish's clipboard anyway... :p
Freso liljencrantz: Is xsel a part of X.org or a package entirely for itself?
liljencrantz jamessan: Yes. It looks for xsel in the PATH.
Freso freso@nayru ~> equery b xsel
Freso [ Searching for file(s) xsel in *... ]
Freso app-shells/fish-1.21.1 (/usr/bin/xsel)
Freso freso@nayru ~>
Freso Not in X.org at least.
Freso I wonder what the virtual/x11 dependency is for then.
jamessan Freso: it's independently developed.
http://www.vergenet.net/~conrad/software/xsel/
Freso Nice.
Freso I might end up actually using that, now.
Freso I'm assuming xsel, then, needs X.
jamessan it depends on some X libraries, yeah
Freso But fish doesn't ask for anything other X than xsel, right?
liljencrantz Freso: I really like the way xsel is used in fish. Mostly because
I don't have to touch the really icky X stuff needed to implement clipboard
support, but also since this means that fish does not need to include or even
know about X; that bit is all handled by xsel.
liljencrantz Freso: Right, fish only needs X to compile xsel, not directly.
Freso liljencrantz: Right. I'm going to file two more bugs then - one asking to
have xsel added to portage, the other asking to remove xsel from ebuild,
depending on a USE flag. (Probably 'X'.)
Freso liljencrantz: Do you want to be cc'd on either?
liljencrantz Freso: That's pretty much what I thought would be the way ahead.
Keep in mind, though, that there is no reason to remove xsel from fish _Before_
there is a working xsel package.
Freso Yeah. :)
Freso I was going to mark the xsel request a blocker for the other one.
liljencrantz Freso: Regarding CC's, I said this just after you where
disconnected a few minutes ago: 'And btw, I don't mind beeing added to CCs for
distro bugs. It's nice to know what's happening'

Request for XSel package in bug #126405.

I would say that the 'X' USE flag should be utilised for the purpose of XSel
support.
Note jamessan's point that if 'xsel' is available (in PATH), it will still be
used regardless of whether 'support' was built for it or not.

Uhm, can't we just make xsel compile conditional on X use flag, instead of a
new ebuild? Anyway, fish depends only on two libs (libSM and liXext) w/ modular
X, see the ebuild. 

Well, yes, one could do that. But wouldn't it be cleaner to have xsel as a
separate package altogether? You wouldn't need to recompile xsel with new
versions of fish, and vice versa. (fish seems to have a higher release rate
than xsel though - but then, why fix something that isn't broken? :))
Also, from what I could gather, Axel wants to remove the xsel source from
fish's source (feel free to correct me :)), so we might have to install it by
itself eventually anyway.

And yes I saw those two libs in the latest ebuild, however modular X isn't here
just yet and removing any and all X dependencies should be possible. If someone
wants to use fish on a box with no X, they currently need to install fish
manually or hack the build.

*** This bug has been marked as a duplicate of 131638 ***