FISH includes some python scripts, e.g., used by fish_update_completions, and yet app-shells/fish has no python dependencies. Furthermore, support for xz/lzma compressed man pages is optional, yet there is no USE flag to control this. Attached is a patch (originally from bug #488518) that - adds lzma and xz USE flags, which must both be (de-)activated together, since the lzma module cannot support only one or the other, and - adds code to handle the python dependencies via the python-r1 eclass. Strictly speaking, all versions of fish are missing Python dependencies, but the patch is against app-shells/fish-2.1.0-r1. Reproducible: Always % emerge --info Portage 2.2.7 (default/linux/amd64/13.0, gcc-4.7.3, glibc-2.15-r3, 3.10.17-gentoo x86_64) ================================================================= System uname: Linux-3.10.17-gentoo-x86_64-Intel-R-_Core-TM-_i3_CPU_M_350_@_2.27GHz-with-gentoo-2.2 KiB Mem: 1910356 total, 445304 free KiB Swap: 8191996 total, 8183244 free Timestamp of tree: Mon, 04 Nov 2013 23:15:01 +0000 ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p45 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.7.5-r3, 3.2.5-r3 dev-util/cmake: 2.8.11.2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6, 1.13.4 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.7.3-r1 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.9 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo science proaudio mjoliet Installed sets: @audio-base, @desktop-apps, @desktop-base, @desktop-misc, @devel-audio, @devel-base, @devel-python, @latex, @local-arthur, @science, @sys-base, @sys-utils, @work ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -march=native -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps=y --quiet-build=y --nospinner" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="ftp://de-mirror.org/gentoo/ ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo ftp://mirror.netcologne.de/gentoo/" LANG="de_DE.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-s -j5" PKGDIR="/usr/portage/packages" PORTAGE_COMPRESS="xz" PORTAGE_COMPRESS_FLAGS="-9" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/science /var/lib/layman/pro-audio /usr/local/portage/marcec" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac acl alsa amd64 avahi berkdb branding bzip2 cairo caps cdinstall cjk cli consolekit cracklib crypt css cups cxx dbus dga djvu dri dssi dts dvd encode exif fbcon ffmpeg fftw fish-completion flac fortran ftp fuse gdbm gif gmp gnuplot gnutls gtk iconv idn imlib inotify ipv6 jack jackmidi jpeg jpeg2k kipi ladspa lapack lash latex lcms libnotify libsamplerate logrotate lzma mad mjpeg mmx mmxext mng modplug modules mp3 mp4 mpeg mudflap multilib musepack musicbrainz ncurses nfs nls nptl ntp offensive ogg openexr opengl openmp opus osc pam pango pcre pdf plotutils png policykit pulseaudio qt4 quicktime rar readline rtsp samba sasl session sid slang smp sndfile speex spell sse sse2 sse3 sse4 ssl ssse3 startup-notification svg sysfs taglib tcpd theora threads tiff timidity truetype unicode usb v4l vaapi vdpau vim-syntax vorbis vpx webkit wma x264 xattr xcb xcomposite xface xft xml xmp xpm xscreensaver xv xvid zeroconf zlib zsh-completion" ABI_X86="64" ALSA_CARDS="hda-intel usb-audio" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en_US en en_GB de" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="intel vesa" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Created attachment 362624 [details, diff] Specify Python dependencies, add xz/lzma USE flags.
Thanks for the patch. I wonder why you are using lzma and xz USE flag as I only see the lzma USE flag actually adding deps to the ebuild. If both lzma and xz USE flag have the same meaning we should stick to one (I'd prefer xz) USE flag rather than adding too much complexity. Furthermore, when the USE flags only add runtime dependencies, I'd rather make these deps non-optional as there would be no sane way to disable lzma/xz support in fish. What do you think?
(In reply to Lars Wendler (Polynomial-C) from comment #2) > Thanks for the patch. > I wonder why you are using lzma and xz USE flag as I only see the lzma USE > flag actually adding deps to the ebuild. Because you have to have both (un-)set simultaneously, therefore only one of them needs to add dependencies. > If both lzma and xz USE flag have the same meaning we should stick to one > (I'd prefer xz) USE flag rather than adding too much complexity. My thought process was: - In python, you can only support xz and lzma compression simultaneously, but - the lzma USE flag description only alludes to LZMA compression (obviously), therefore - to fully describe what is happening (adding xz and lzma support), you'd need both USE flags, and force them to be active/inactive simultaneously (hence the REQUIRED_USE). So if there were to be only one USE flag, you would run into the problem of the USE flag description being inadequate. Actually, I just had an idea... perhaps it would be better to have only the lzma USE flag (since the relevant python module is named lzma) and change the local USE flag description to match. What do you think? > Furthermore, when the USE flags only add runtime dependencies, I'd rather > make these deps non-optional as there would be no sane way to disable > lzma/xz support in fish. > > What do you think? I'm not sure myself. I would argue that maybe a user doesn't want xz or lzma on their system, then fish wouldn't unnecessarily pull it in (unless they have Python 3.3 installed).
(In reply to Marc Joliet from comment #3) > (In reply to Lars Wendler (Polynomial-C) from comment #2) > > Thanks for the patch. > > I wonder why you are using lzma and xz USE flag as I only see the lzma USE > > flag actually adding deps to the ebuild. > > Because you have to have both (un-)set simultaneously, therefore only one of > them needs to add dependencies. Yeah but why confusing the user with the illusion they actually can choose between both flags when they really cannot? > > If both lzma and xz USE flag have the same meaning we should stick to one > > (I'd prefer xz) USE flag rather than adding too much complexity. > > My thought process was: > - In python, you can only support xz and lzma compression simultaneously, but > - the lzma USE flag description only alludes to LZMA compression > (obviously), therefore > - to fully describe what is happening (adding xz and lzma support), you'd > need both USE flags, and force them to be active/inactive simultaneously > (hence the REQUIRED_USE). > > So if there were to be only one USE flag, you would run into the problem of > the USE flag description being inadequate. Actually, I just had an idea... > perhaps it would be better to have only the lzma USE flag (since the > relevant python module is named lzma) and change the local USE flag > description to match. What do you think? As xz is the successor of lzma this doesn't really make a difference. app-arch/xz-utils also has support for lzma and was previously called lzma-utils. As far as I know we only use the lzma USE flag when a package _only_ supports lzma but not xz. If a package supports both implementations we usually stick to the xz USE flag. > > Furthermore, when the USE flags only add runtime dependencies, I'd rather > > make these deps non-optional as there would be no sane way to disable > > lzma/xz support in fish. > > > > What do you think? > > I'm not sure myself. I would argue that maybe a user doesn't want xz or lzma > on their system, then fish wouldn't unnecessarily pull it in (unless they > have Python 3.3 installed). Yeah but the USE flag does not really change behaviour of anything in the fish package. Adding USE flags to ebuilds just for the purpose of adding further package-dependencies generally is highly discouraged in portage. So we have two choices here: - Adding the dependencies for python's lzma/xz support unconditionally - Let the ebuild emit an elog message telling users to install the corresponding python packages when they want to have working lzma/xz support in fish.
(In reply to Lars Wendler (Polynomial-C) from comment #4) > (In reply to Marc Joliet from comment #3) > > (In reply to Lars Wendler (Polynomial-C) from comment #2) > > > Thanks for the patch. > > > I wonder why you are using lzma and xz USE flag as I only see the lzma USE > > > flag actually adding deps to the ebuild. > > > > Because you have to have both (un-)set simultaneously, therefore only one of > > them needs to add dependencies. > > Yeah but why confusing the user with the illusion they actually can choose > between both flags when they really cannot? > > > > If both lzma and xz USE flag have the same meaning we should stick to one > > > (I'd prefer xz) USE flag rather than adding too much complexity. > > > > My thought process was: > > - In python, you can only support xz and lzma compression simultaneously, but > > - the lzma USE flag description only alludes to LZMA compression > > (obviously), therefore > > - to fully describe what is happening (adding xz and lzma support), you'd > > need both USE flags, and force them to be active/inactive simultaneously > > (hence the REQUIRED_USE). > > > > So if there were to be only one USE flag, you would run into the problem of > > the USE flag description being inadequate. Actually, I just had an idea... > > perhaps it would be better to have only the lzma USE flag (since the > > relevant python module is named lzma) and change the local USE flag > > description to match. What do you think? > > As xz is the successor of lzma this doesn't really make a difference. > app-arch/xz-utils also has support for lzma and was previously called > lzma-utils. > As far as I know we only use the lzma USE flag when a package _only_ > supports lzma but not xz. If a package supports both implementations we > usually stick to the xz USE flag. OK, I was unaware of that convention. Then xz it is! > > > Furthermore, when the USE flags only add runtime dependencies, I'd rather > > > make these deps non-optional as there would be no sane way to disable > > > lzma/xz support in fish. > > > > > > What do you think? > > > > I'm not sure myself. I would argue that maybe a user doesn't want xz or lzma > > on their system, then fish wouldn't unnecessarily pull it in (unless they > > have Python 3.3 installed). > > Yeah but the USE flag does not really change behaviour of anything in the > fish package. Adding USE flags to ebuilds just for the purpose of adding > further package-dependencies generally is highly discouraged in portage. Ah, thanks for cluing me in on that. > So we have two choices here: > > - Adding the dependencies for python's lzma/xz support unconditionally > > - Let the ebuild emit an elog message telling users to install the > corresponding python packages when they want to have working lzma/xz support > in fish. In that case, I would go the unconditional route, since it's only a matter of time (albeit maybe a few years ;) ) before there are no more Python versions that don't have the lzma module in their standard library (at least in Gentoo; the fish team appeared to be more concerned with distros like Red Hat when they requested for lzma/xz support to be optional). I'll post an updated patch soon.
Created attachment 362636 [details, diff] Specify Python dependencies. OK, here's an updated patch that unconditionally supports xz/lzma, so I removed the xz and lzma USE flags. Is this OK?
(In reply to Marc Joliet from comment #6) > Created attachment 362636 [details, diff] [details, diff] > Specify Python dependencies. > > OK, here's an updated patch that unconditionally supports xz/lzma, so I > removed the xz and lzma USE flags. Is this OK? Your patch looks good and I'd like to apply it. Unfortunately dev-python/backports-lzma is not keyworded for ppc architecture but fish is. So right now I can only go with option Nr. 2 unless I can convince ppc arch team to keyword dev-python/backports-lzma.
(In reply to Lars Wendler (Polynomial-C) from comment #7) > (In reply to Marc Joliet from comment #6) > > Created attachment 362636 [details, diff] [details, diff] [details, diff] > > Specify Python dependencies. > > > > OK, here's an updated patch that unconditionally supports xz/lzma, so I > > removed the xz and lzma USE flags. Is this OK? > > Your patch looks good and I'd like to apply it. Unfortunately > dev-python/backports-lzma is not keyworded for ppc architecture but fish is. > So right now I can only go with option Nr. 2 unless I can convince ppc arch > team to keyword dev-python/backports-lzma. I don't know the ppc arch team or what the keywording process is like, but since backports-lzma is derived from the python 3.3 lzma module, and all of python is {~,}ppc, I would be surprised if it were difficult to convince them. I suppose I would just open a bug requesting backports-lzma be keyworded ~ppc and have it block this bug.
Okay the KEYWORDS problem is even more tricky. The fish-2.1.0 ebuild contains the following KEYWORDS: ~amd64 ~ppc ~x86 ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~x86-solaris Whereas teh dev-python/backports-lzma ebuilds only contain: ~amd64 ~x86 ~amd64-linux ~x86-linux So I can now either - Open a bug for backports-lzma and request addition of necessary missing keywords which might take veeery long. - Keep the dependencies on backports-lzma and >=python-3.3 out of fish and stick with an elog message that tells the users what they need to install in order to get proper man-page completion. Personally I'd prefer the latter option. What do you think?
(In reply to Lars Wendler (Polynomial-C) from comment #9) > Okay the KEYWORDS problem is even more tricky. The fish-2.1.0 ebuild > contains the following KEYWORDS: > > ~amd64 ~ppc ~x86 ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~x86-solaris > > Whereas teh dev-python/backports-lzma ebuilds only contain: > > ~amd64 ~x86 ~amd64-linux ~x86-linux Yeah, that might be a problem :( . > So I can now either > > - Open a bug for backports-lzma and request addition of necessary missing > keywords which might take veeery long. > > - Keep the dependencies on backports-lzma and >=python-3.3 out of fish and > stick with an elog message that tells the users what they need to install in > order to get proper man-page completion. > > Personally I'd prefer the latter option. What do you think? I have no problem with the latter option, but would prefer it if you open a bug anyway so that it can be referred to in the ebuild.
+*fish-2.1.0-r2 (11 Feb 2014) + + 11 Feb 2014; Lars Wendler <polynomial-c@gentoo.org> -fish-1.23.1.ebuild, + -fish-1.23.1-r2.ebuild, fish-2.0.0.ebuild, -fish-2.1.0-r1.ebuild, + +fish-2.1.0-r2.ebuild: + Added an elog message to install python for making manpage-completion + functional (bug #490478). Removed www-client/htmlview from RDEPEND and added + an elog note how to make the help system work (bug #488012). Removed old + versions. + Sorry for the long delay.
