Re: [gentoo-dev] Update to the pax-utils.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/26/2014 06:23 PM, Anthony G. Basile wrote: > On 08/26/14 17:00, Alexander Tsoy wrote: >> On Tue Aug 26 22:27:36 2014 Anthony G. Basile >> wrote: >>> Hi everyone, >>> >>> I plan to update the pax-utils.eclass because of bug #520198. Can >>> people please review that bug and the latest suggestion for the eclass. >>> Since I'm inverting some if and for blocks, a diff isn't as useful as >>> just looking at the entire class. >>> >> What if scanelf will fail? Looks like pax-mark() will not report an >> error. > > scanelf doesn't return an error code on failing to pax mark. The paxctl > and paxctl-ng do. eg. Maybe we should read the pax marks back to verify if it works or not instead of trusting the return code? We could do it just for scanelf. - -Zero > > blueness@yellow /tmp $ rm -f abc > blueness@yellow /tmp $ touch abc > blueness@yellow /tmp $ scanelf -Xx abc >/dev/null ; echo $? > 0 > > If you want a more sophisticated example, remove the PT_PAX_FLAGS > program header from an elf and you get the same results. I don't think > its wise to change the behavior of scanelf because its used in portage > eg in constructing NEEDED.ELF.2. So its not clear what the unintended > consequences would be if we did report an error here. vapier would be > able to better address that. I just wrote the eclass following the > current behaviour. > >> >> And there are unused variables in pax-mark(): pt_fail* and xt_fail*. >> > > Thanks for catching the cruft. > > -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJT/TKeAAoJEKXdFCfdEflKYB0QAKB/qpHKdqBkoG2lB9dH+1RG qIEyqHdf/SFDem31n1WO5On14enSn+cxafltTvg0emL34emg8v1Y0qD3s0CqXt4K juX3X8tCnT0CMME/Q4+mgs7aF2+/SLKliUQQ0H842xSSgBGS6uXy6hLa9p0wLOGL l9tzSjHGDBuTFdqZEqWiPVKOWw5loKZto0w8z6xHyFicEvNGGIaUZcpvvHs8dM26 aDICXrWqbU6dP8rU2AA8CSapEoFjuOQHQWPCzaIGlABSb9X9N/dbeS27bVQdiQm4 MBOEJHr9EPYwRRFJ8/XagCRDe3gUgh9p+WROnHZVblMkKRbUJvLqyYSLT220hdRi lwFJb8kiXfP446jk821wu2xbf0DYCuqOJFTUL/2lcXUO7atIQJqOlOYlpfL7IGSn RYKxDaJSoaxuGkMsqgKcp9gZ8AD/VT6uD1r6iTTkmCAnVQj4UB02XDc+r6+coyUc PTjyDiOeQHUhjvoWuJBxAT+TWNZRWXdIkIS1CzGHuCoovGyba+k9JfsOmmFX1HNR vFzSnOZ+AwIZSk0Mwbm7yeigrXlnPax3D7cRAACif9+fgkXolYr7NYZWgUuEYmDg 0BAjAsnK1Hr+UhQ6PmcLy8DH5svV9WaQcTWEGDHkEqavpZG3bqv/XKePXS//9MxK rq52G8MW2QlYGVFJd8ZR =5Kdh -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] qt5-build.eclass
On Wed, Aug 20, 2014 at 10:07 AM, Michał Górny wrote:
> Dnia 2014-08-17, o godz. 20:38:18
> Davide Pesavento napisał(a):
>
>> # @FUNCTION: qt5-build_src_unpack
>> # @DESCRIPTION:
>> # Unpacks the sources.
>> qt5-build_src_unpack() {
>> if [[ $(gcc-major-version) -lt 4 ]] || [[ $(gcc-major-version) -eq 4
>> && $(gcc-minor-version) -lt 5 ]]; then
>> ewarn
>> ewarn "Using a GCC version lower than 4.5 is not supported."
>> ewarn
>> fi
>>
>> if [[ ${PN} == qtwebkit ]]; then
>> eshopts_push -s extglob
>> if is-flagq '-g?(gdb)?([1-9])'; then
>
> Wouldn't that be equivalent to '-g[^0]'? And I think this would
> actually work without extglob.
That doesn't match '-g' though, does it?
>
>> ewarn
>> ewarn "You have enabled debug info (probably have -g
>> or -ggdb in your CFLAGS/CXXFLAGS)."
>> ewarn "You may experience really long compilation
>> times and/or increased memory usage."
>> ewarn "If compilation fails, please try removing
>> -g/-ggdb before reporting a bug."
>> ewarn "For more info check out
>> https://bugs.gentoo.org/307861";
>> ewarn
>> fi
>> eshopts_pop
>> fi
>>
>> case ${QT5_BUILD_TYPE} in
>> live)git-r3_src_unpack ;;
>> release) default ;;
>> esac
>> }
>>
>> # @FUNCTION: qt5-build_src_prepare
>> # @DESCRIPTION:
>> # Prepares the sources before the configure phase.
>> qt5-build_src_prepare() {
>> qt5_prepare_env
>>
>> if [[ ${QT5_MODULE} == qtbase ]]; then
>> # Avoid unnecessary qmake recompilations
>> sed -i -re "s|^if true;.*(\[
>> '\!').*(\"\\\$outpath/bin/qmake\".*)|if \1 -e \2 then|" \
>> configure || die "sed failed (skip qmake bootstrap)"
>
> Any chance for something more readable? :) Like a inline patch.
I think it's a fairly straightforward substitution, not pretty maybe
but... heh ;) Also, it's not something that you have to look at all
the time since the configure line doesn't change often, and the intent
is clear from the comment, so I'm not going to change it.
>
>> # Respect CC, CXX, *FLAGS, MAKEOPTS and EXTRA_EMAKE when
>> bootstrapping qmake
>> sed -i -e "/outpath\/qmake\".*\"\$MAKE\")/ s:): \
>> ${MAKEOPTS} ${EXTRA_EMAKE} 'CC=$(tc-getCC)'
>> 'CXX=$(tc-getCXX)' \
>> 'QMAKE_CFLAGS=${CFLAGS}' 'QMAKE_CXXFLAGS=${CXXFLAGS}'
>> 'QMAKE_LFLAGS=${LDFLAGS}'&:" \
>> -e '/"$CFG_RELEASE_QMAKE"/,/^\s\+fi$/ d' \
>> configure || die "sed failed (respect env for qmake
>> build)"
>
> Ditto ;).
ditto ;)
>
>> sed -i -e '/^CPPFLAGS\s*=/ s/-g //' \
>> qmake/Makefile.unix || die "sed failed (CPPFLAGS for
>> qmake build)"
>>
>> # Respect CXX in {bsymbolic_functions,fvisibility,precomp}.test
>> sed -i -e "/^QMAKE_CONF_COMPILER=/ s:=.*:=\"$(tc-getCXX)\":" \
>> configure || die "sed failed (QMAKE_CONF_COMPILER)"
>>
>> # Respect toolchain and flags in config.tests
>> find config.tests/unix -name '*.test' -type f -print0 \
>> | xargs -0 sed -i -e '/bin\/qmake/ s/-nocache //' \
>> || die "sed failed (config.tests)"
>
> find ... -exec sed ... {} +
>
>> fi
>>
>> if [[ ${PN} != qtcore ]]; then
>> qt5_symlink_tools_to_build_dir
>> fi
>>
>> # apply patches
>> [[ ${PATCHES[@]} ]] && epatch "${PATCHES[@]}"
>> epatch_user
>> }
>
> [...]
>
>> # @FUNCTION: qt5-build_src_install
>> # @DESCRIPTION:
>> # Performs the actual installation of target directories.
>> qt5-build_src_install() {
>> qt5_foreach_target_subdir emake INSTALL_ROOT="${D}" install
>>
>> if [[ ${PN} == qtcore ]]; then
>> pushd "${QT5_BUILD_DIR}" >/dev/null || die
>> einfo "Running emake INSTALL_ROOT=${D}
>> install_{mkspecs,qmake,syncqt}"
>
> You can put that command-line in an array or set to argv.
>
>> emake INSTALL_ROOT="${D}" install_{mkspecs,qmake,syncqt}
>> popd >/dev/null || die
>>
>> # install an empty Gentoo/gentoo-qconfig.h in ${D}
>> # so that it's placed under package manager control
>> > "${T}"/gentoo-qconfig.h
>> (
>> insinto "${QT5_HEADERDIR#${EPREFIX}}"/Gentoo
>> doins "${T}"/gentoo-qconfig.h
>> )
>>
>> # include gentoo-qconfig.h at the beginning of QtCore/qconfig.h
>> sed -i -e '1a#include \n' \
>> "${D}${QT5_HEADERDIR}"/QtCore/qconfig.h \
>> || die "sed failed (qconfig.h)"
>> fi
>>
>> qt5_insta
Re: [gentoo-dev] bash-completion-2.1-r1 once again
Dnia 2014-08-26, o godz. 23:35:16
Michał Górny napisał(a):
> Dnia 2014-08-26, o godz. 12:51:22
> Michał Górny napisał(a):
>
> > I think the best way forward is to:
> >
> > 1. Teach 'old' eselect-bashcomp to find files in the new $completionsdir
> > as well as the old location, and stabilize that soon.
> >
> > 2. Switch the eclass and ebuilds to use the new $completionsdir. While
> > at it, make sure that ebuilds install completion files whose names
> > conform to the new layout (portage QA check likely).
> >
> > 3. Do we need some specific documentation except for a regular news
> > item? Where?
> >
> > 4. Unmask the new bash-completion and eselect-bashcomp. Add a news item
> > explaining the sudden change :).
>
> A bit more details to the plan:
>
>
> 1. Bump app-admin/eselect-bashcomp (or app-shells/bash-completion)
> to install env.d file with ES_BASHCOMP_DIRS pointing to the new
> $completionsdir.
>
> [...]
>
> 2. Change bash-completion-r1.eclass default to /completions subdir.
>
> [...]
>
> 3. Bump app-shells/bash-completion to respect current $completionsdir.
>
> [...]
If anyone wishes to review this further, attached bash-completion
ebuild changes for (1) and (3), and eclass changes for (2). Tested
and confirmed working.
--
Best regards,
Michał Górny
--- bash-completion-2.1.ebuild 2014-01-19 11:12:43.0 +0100
+++ bash-completion-2.1-r1.ebuild 2014-08-27 00:19:35.277605486 +0200
@@ -3,7 +3,7 @@
# $Header: /var/cvsroot/gentoo-x86/app-shells/bash-completion/bash-completion-2.1.ebuild,v 1.6 2014/01/19 10:12:43 vapier Exp $
EAPI=5
-inherit prefix
+inherit bash-completion-r1 prefix
DESCRIPTION="Programmable Completion for bash"
HOMEPAGE="http://bash-completion.alioth.debian.org/";
@@ -23,6 +23,14 @@ src_prepare() {
cp "${FILESDIR}"/bash-completion.sh-gentoo-1.2 "${T}"/bash-completion.sh || die
eprefixify "${T}"/bash-completion.sh
+ cp "${FILESDIR}"/bash-completion.pc "${T}"/ || die
+ # reuse paths from the eclass -- those can come from pkg-config
+ # or defaults.
+ sed -i \
+ -e "/completionsdir/s@=.*\$@=$(get_bashcompdir)@" \
+ -e "/helpersdir/s@=.*\$@=$(get_bashhelpersdir)@" \
+ "${T}"/bash-completion.pc || die
+
find completions -name 'Makefile*' -exec rm -f {} +
# Part of >=sys-apps/util-linux-2.23 wrt #468544
@@ -36,6 +44,10 @@ src_prepare() {
# net-misc/networkmanager:
rm -f completions/nmcli
+
+ # Forward-compatibility with new install location, for eselect-bashcomp.
+ echo "ES_BASHCOMP_DIRS=\"${EPREFIX}/usr/share/bash-completion/completions\"" \
+ > "${T}"/50bash_completion || die
}
src_configure() { :; } # no-op
@@ -47,8 +59,7 @@ src_install() {
doins "${T}"/bash-completion.sh
# All files from contrib/ in source package get installed
- insinto /usr/share/bash-completion
- doins -r "${S}"/completions/*
+ dobashcomp "${S}"/completions/*
awk -v D="$ED" '
BEGIN { out=".pre" }
@@ -68,7 +79,9 @@ src_install() {
# Installed to datadir instead of libdir because bash-completion(s)
# are not ELF files.
insinto /usr/share/pkgconfig
- doins "${FILESDIR}"/bash-completion.pc
+ doins "${T}"/bash-completion.pc
+
+ doenvd "${T}"/50bash_completion
}
pkg_postinst() {
Index: bash-completion-r1.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/bash-completion-r1.eclass,v
retrieving revision 1.12
diff -u -B -r1.12 bash-completion-r1.eclass
--- bash-completion-r1.eclass 22 Jan 2014 19:41:21 - 1.12
+++ bash-completion-r1.eclass 26 Aug 2014 22:24:29 -
@@ -57,7 +57,7 @@
_bash-completion-r1_get_bashcompdir() {
debug-print-function ${FUNCNAME} "${@}"
- _bash-completion-r1_get_bashdir completionsdir /usr/share/bash-completion
+ _bash-completion-r1_get_bashdir completionsdir /usr/share/bash-completion/completions
}
# @FUNCTION: _bash-completion-r1_get_helpersdir
signature.asc
Description: PGP signature
Re: [gentoo-dev] Update to the pax-utils.eclass
On 08/26/14 17:00, Alexander Tsoy wrote: On Tue Aug 26 22:27:36 2014 Anthony G. Basile wrote: Hi everyone, I plan to update the pax-utils.eclass because of bug #520198. Can people please review that bug and the latest suggestion for the eclass. Since I'm inverting some if and for blocks, a diff isn't as useful as just looking at the entire class. What if scanelf will fail? Looks like pax-mark() will not report an error. scanelf doesn't return an error code on failing to pax mark. The paxctl and paxctl-ng do. eg. blueness@yellow /tmp $ rm -f abc blueness@yellow /tmp $ touch abc blueness@yellow /tmp $ scanelf -Xx abc >/dev/null ; echo $? 0 If you want a more sophisticated example, remove the PT_PAX_FLAGS program header from an elf and you get the same results. I don't think its wise to change the behavior of scanelf because its used in portage eg in constructing NEEDED.ELF.2. So its not clear what the unintended consequences would be if we did report an error here. vapier would be able to better address that. I just wrote the eclass following the current behaviour. And there are unused variables in pax-mark(): pt_fail* and xt_fail*. Thanks for catching the cruft. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] bash-completion-2.1-r1 once again
Dnia 2014-08-26, o godz. 12:51:22 Michał Górny napisał(a): > I think the best way forward is to: > > 1. Teach 'old' eselect-bashcomp to find files in the new $completionsdir > as well as the old location, and stabilize that soon. > > 2. Switch the eclass and ebuilds to use the new $completionsdir. While > at it, make sure that ebuilds install completion files whose names > conform to the new layout (portage QA check likely). > > 3. Do we need some specific documentation except for a regular news > item? Where? > > 4. Unmask the new bash-completion and eselect-bashcomp. Add a news item > explaining the sudden change :). A bit more details to the plan: 1. Bump app-admin/eselect-bashcomp (or app-shells/bash-completion) to install env.d file with ES_BASHCOMP_DIRS pointing to the new $completionsdir. It seems that ES_BASHCOMP_DIRS variable wasn't actually ever used but it was in the eselect module all the time. While this doesn't change anything at the moment, it will allow the completions to be moved to the new location without having to switch directly to the new scheme. This is mostly intended to help keep stable working. 2. Change bash-completion-r1.eclass default to /completions subdir. While this may sound harsh, it doesn't really change anything to existing users. Wherever bash-completion is installed, the eclass uses pkg-config to determine the paths and therefore it will keep using the old paths on those systems. However, new installs (and people not having bash-completion installed) will start moving to the new path. For existing users, the files will be installed in the same location to keep symlinks working. This way, they won't have to re-enable completions due to file moves. And once they switch to the new scheme, they will be able to move files via a single rebuild and they won't need working symlinks in compatdir anymore :). For new users, the files will already start being installed in the new location. If they decide to enable bash-completion before the new scheme goes live, the updated eselect will be able to find files in the new location. If they do it post-switch, they will have the files in correct location anyway. 3. Bump app-shells/bash-completion to respect current $completionsdir. Use a trick similar to the one used for udevdir in sys-apps/systemd. Instead of using a default install path, query pkg-config for the current one and reuse it. That is, until we switch to the new scheme. The goal here is similar. Existing users will get bash-completion installed wherever it were, and new users will get it installed to the new location (but without the new logic). This way, installing bash-completion on new systems won't result in moving files back to the old location. 4. Start playing with the new scheme :). Once all safety and compatibility logic is in place, I believe I can commit the first testing version of new bash-completion p.masked. I think I'm going to start committing this tomorrow. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Update to the pax-utils.eclass
On Tue Aug 26 22:27:36 2014 Anthony G. Basile wrote: > Hi everyone, > > I plan to update the pax-utils.eclass because of bug #520198. Can > people please review that bug and the latest suggestion for the eclass. > Since I'm inverting some if and for blocks, a diff isn't as useful as > just looking at the entire class. > What if scanelf will fail? Looks like pax-mark() will not report an error. And there are unused variables in pax-mark(): pt_fail* and xt_fail*. -- Alexander Tsoy
[gentoo-dev] Lastrite: media-sound/cowbell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Kristian Fiskerstrand (26 Aug 2014) # Open security bug #386221 (CVE-2010-3353) # Does not seem actively maintained # Masked for removal in 30 days media-sound/cowbell - -- Kristian Fiskerstrand Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJT/NnBAAoJEPw7F94F4Tagp/MQALde5+ZXbQLE6qO74DG+79X6 1t+f05kqwX8wjmW1bwagfbFo2z/NEun1j4bhL+DOlh8tTKl6WvfaCH/ADN6KcQqK Pf0zzG0Pmr/B9g5CfMG7VU4iEaxBAsauNWvEbcEwgbHneHcvgAFgQfTTJFOAbGlA SEZfKxCHc3SJdlRowVKeu+MKBmKwNR+WtgQ9nnv4muY46AwDUjEV15DbaduWW3LV a/56nEaN4ho7Afzf9XPyTjVsm802MgYS31FH33BLJK+urjG1JzaQVqP/hlp3eknO BMs9cj/vnZWzQAuiMT6x2xnhpVE6zS43bew97zo+NhgNXS9J1DnKA9Jfma0GBJxu MF5U+bD6qihkFgf1okWcIOE9qviQOgt1E5yCCcM901Nc02uVSI7jrTbrnJHVy3pT qjR2xXvJgR0JkltsLiEjKgw5/5zM1TCWhp6vouU0VLCPhTyF3SBUMx2t/yMfT5TE 79oDl0b5iKWpf03DXytM1xssOdUeApdGjQHW8b7I17JK6QzkCn/hMEPwSv+B/eR9 LL/7ZHYy/Vaioq5NvMobDjFYMsp3+Jq28ZAPh9pApM88oqswgwGYJzMwxeh6zQ43 VTtPM4J4p+K6twNqjIBD2wYvQbl8u3VMMy7zCkcNn3SjmPZofR2eRCCklylGUEKu opiZhrT5+UQT1rDNLNwK =iZ+w -END PGP SIGNATURE-
Re: [gentoo-dev] bash-completion-2.1-r1 once again
Dnia 2014-08-26, o godz. 15:42:42 Alexander Tsoy napisał(a): > Several packages install completions into compatdir > (/etc/bash_completion.d) by default. And these completions are > incompatible with autoloader, so they will not work if you simply > install them into completionsdir and create necessary symlinks. One > example is sys-boot/grub [1]. What do you plan to do with such packages? > > [1] https://bugs.gentoo.org/show_bug.cgi?id=477392 Are there any non-trivial issues like this? As far as I can see, this particular issue is about using deprecated 'have' function. Fixing it would be quite trivial, similarly fixing missing symlinks. I'm aware of two non-trivial breakages with new scheme: 1. git-prompt that wasn't really a completion, so it couldn't work like one :), 2. /etc/init.d/* completion can't work since it relies on absolute paths and the autoloader works with relative only. If we find a fair number of issues needing support for compatdir, I guess we can end up with dual-mode 'eselect bashcomp'. Otherwise, I'd rather focus on fixing offenders. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Update to the pax-utils.eclass
Hi everyone, I plan to update the pax-utils.eclass because of bug #520198. Can people please review that bug and the latest suggestion for the eclass. Since I'm inverting some if and for blocks, a diff isn't as useful as just looking at the entire class. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] bash-completion-2.1-r1 once again
В Tue, 26 Aug 2014 12:51:22 +0200 Michał Górny пишет: > What needs to change? > - > > The major issue is how to switch the system properly -- preferably, > without forcing users to reinstall everything :). > > I think the best way forward is to: > > 1. Teach 'old' eselect-bashcomp to find files in the new $completionsdir > as well as the old location, and stabilize that soon. > > 2. Switch the eclass and ebuilds to use the new $completionsdir. While > at it, make sure that ebuilds install completion files whose names > conform to the new layout (portage QA check likely). > > 3. Do we need some specific documentation except for a regular news > item? Where? > > 4. Unmask the new bash-completion and eselect-bashcomp. Add a news item > explaining the sudden change :). > > Any comments? Doubts? Wishes? > Several packages install completions into compatdir (/etc/bash_completion.d) by default. And these completions are incompatible with autoloader, so they will not work if you simply install them into completionsdir and create necessary symlinks. One example is sys-boot/grub [1]. What do you plan to do with such packages? [1] https://bugs.gentoo.org/show_bug.cgi?id=477392 -- Alexander Tsoy
Re: [gentoo-dev] bash-completion-2.1-r1 once again
Dnia 2014-08-26, o godz. 07:13:53 Joshua Kinard napisał(a): > > oldcompdir = /usr/share/bash-completion > [...] > > completionsdir = /usr/share/bash-completion/completions > [snip] > > I take it systems with /usr mounted separately won't be affected by this > change? Do we need to retain the /etc/bash_completion.d compatdir in any > form? Nope, the files are just moving one directory deeper (as you can see in the chopped snippet). As for compatdir, bash will still support it though there will be no need to use it for conforming completions. Users switching to the new system will likely want to remove it since it will preload the previously-enabled completions unnecessarily. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] bash-completion-2.1-r1 once again
On 08/26/2014 06:51, Michał Górny wrote: > Hello, developers and users. > > I would like to champion the goal of bringing bash-completion-2.1-r1 to > Gentoo. As far as I can see, nobody's been working on this since > the first failed attempt has been reverted. > > Firstly, I would like to describe the differences between the old > and the new system. > > > The old system > -- > > compatdir = /etc/bash_completion.d > oldcompdir = /usr/share/bash-completion > > 1. Completions and other completion-like files are installed > in $oldcompdir. > > 2. On start, bash sources all files from $compatdir, explicitly > enabling completions inside them. > > 3. 'eselect bashcomp' enables completions through linking files > from $oldcompdir to $compatdir. > > > What's wrong with the old system? > - > > Well, the major issue with the old system is that for completion to > work, it needs to loaded at start of bash. The more completions you > enable, the more files bash needs to source and the more memory > consumed. > > If you enable all completions by default, bash would need to load a lot > of functions, most of them not even used during the session. > > > The new system > -- > > completionsdir = /usr/share/bash-completion/completions > [snip] I take it systems with /usr mounted separately won't be affected by this change? Do we need to retain the /etc/bash_completion.d compatdir in any form? -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
[gentoo-dev] bash-completion-2.1-r1 once again
Hello, developers and users.
I would like to champion the goal of bringing bash-completion-2.1-r1 to
Gentoo. As far as I can see, nobody's been working on this since
the first failed attempt has been reverted.
Firstly, I would like to describe the differences between the old
and the new system.
The old system
--
compatdir = /etc/bash_completion.d
oldcompdir = /usr/share/bash-completion
1. Completions and other completion-like files are installed
in $oldcompdir.
2. On start, bash sources all files from $compatdir, explicitly
enabling completions inside them.
3. 'eselect bashcomp' enables completions through linking files
from $oldcompdir to $compatdir.
What's wrong with the old system?
-
Well, the major issue with the old system is that for completion to
work, it needs to loaded at start of bash. The more completions you
enable, the more files bash needs to source and the more memory
consumed.
If you enable all completions by default, bash would need to load a lot
of functions, most of them not even used during the session.
The new system
--
completionsdir = /usr/share/bash-completion/completions
1. Completions are installed in $completionsdir and named after
the commands they complete. If a single completion matches more than
one command, symlinks to additional names need to be created.
2. On start, bash sources only completion autoloader. The loader
automatically loads completions for commands that do not have any
completions defined yet.
3. Completions are enabled by default. 'eselect bashcomp' handles
disabling specific completions through Gentoo-specific instance of
blacklist.
What's good about the new system?
-
The key feature of the new system is that the completions are loaded
on-demand. In other words, we can basically enable all completions by
default without making bash slow or memory-consuming -- at least, until
user tries to use all the completed commands ;).
I should note here that the completions are loaded to fill
the parameters to a command rather than the command itself. That is:
$ xr[tab]
won't load any completions yet. However:
$ xrandr [tab]
will try to load ${completionsdir}/xrandr. If such a file doesn't exist
or is blacklisted, generic completions will be used.
What needs to change?
-
The major issue is how to switch the system properly -- preferably,
without forcing users to reinstall everything :).
I think the best way forward is to:
1. Teach 'old' eselect-bashcomp to find files in the new $completionsdir
as well as the old location, and stabilize that soon.
2. Switch the eclass and ebuilds to use the new $completionsdir. While
at it, make sure that ebuilds install completion files whose names
conform to the new layout (portage QA check likely).
3. Do we need some specific documentation except for a regular news
item? Where?
4. Unmask the new bash-completion and eselect-bashcomp. Add a news item
explaining the sudden change :).
Any comments? Doubts? Wishes?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
