I encounter two bugs when trying to update sys-apps/parted to the new minimum version 1.9.0. First, the configure script cannot find the readline library (installed version = 5.2_p14.ebuild) due a missing softlink from /usr/lib/libreadline.so to /usr/lib/libreadline.so.5: ######## checking for readline in -lreadline... no configure: error: GNU Readline could not be found which is required for the --with-readline (which is enabled by default). Either disable readline support with --without-readline or downloaded and install it from: ftp.gnu.org/gnu/readline Note: if you are using precompiled packages you will also need the development package as well (which may be called readline-devel or something similar). ######## This softlink is removed by the readline ebuild in the src_install phase. When I make the link manually, the configure script proceeds to the next failure due to missing readline header files: ######## checking for readline in -lreadline... yes checking for rl_variable_value in -lreadline... yes checking uuid/uuid.h usability... yes checking uuid/uuid.h presence... yes checking for uuid/uuid.h... yes checking for getopt.h... (cached) yes checking linux/unistd.h usability... yes checking linux/unistd.h presence... yes checking for linux/unistd.h... yes checking readline/readline.h usability... no checking readline/readline.h presence... no checking for readline/readline.h... no configure: error: The headers for GNU Readline could not be found which are required for the --with-readline option. You seem to have the GNU readline library installed but not the headers. These are usually found in a corresponding development package (usually called readline-devel). If you can't find one try: ftp.gnu.org/gnu/readline Alternatively you can disable readline support with --without-readline ######## Other packages like sys-devel/bc continue with the build despite not finding the readline library or headers -- they just disable the support. Since the "readline" USE flag is in the "default/linux" profile, this may be a serious problem. However, it is remarkable that no one else has encountered this bug; I am attaching my system info below in case it is something wrong with my setup. Also, I am attaching the filelist for my readline package. Thanks!
Created attachment 219135 [details] paludis --info sys-libs/readline
Created attachment 219137 [details] paludis -k sys-libs/readline
Workaround: =sys-libs/readline-6.0_p4 does not suffer from these problems. Moreover, none of the packages that were linked against readline-5 could not also use readline-6. So, I installed to readline-6, removed readline-5, and re-installed everything that depends on readline. The system behaves normally, and editor commands in the Python shell (like control-d to escape) work normally unlike before. I will leave it to the devs whether or not to close this bug.
Looking more closely at the ebuilds for readline, it seems that this is by design: install only the versioned shared library for readline-{4,5}, and the symlink and headers for readline-6 to avoid conflicts. I don't think this is the right way to do it, since it assumes that everyone will always upgrade to the latest slot. However, maybe limitations within readline make this annoying to handle. Thus, I am closing the bug as "WONTFIX" ...
If newer parted doesn't work with older readline then we could easily work around it by requiring a newer readline as a build time dependency.
My $0.02: * This seems less than ideal, because it means that every time there is new readline slot (quite possible, since there are already three) the parted dependency will have to be updated. * There is still the problem of readline support in various packages failing silently if you don't have the latest slot installed. * I guess the problem is upstream -- the don't append the major version to the name of the header directory, creating file conflicts, and they don't provide a pkg-config, making it difficult to find different versions of the readline library.
I fear the answer will simply be that you need to keep your system up to date anyhow to prevent problems like these, but let's ask sys-libs/readline maintainers for comments anyway.
if a package requires readline to compile against, then you could simply depend on dev-libs/readline:0 i dont see any bugs in the current readline ebuilds nor the parted source code itself
Then I guess the solution is for every package that depends on readline at compile time to require "sys-libs/readline:0" rather than ">=sys-libs/readline-${SOME_VER}" ? This should work transparently for packages that require a minimum version and not a maximum version. Other packages (like dev-lang/ghc-6.8.2 and older) must have both "sys-libs/readline:0" and "sys-libs/readline:${SLOT}" in their deps.
i dont really see much point. readline SLOT=0 is always going to be installed. the only way SLOT=0 would be removed and a different SLOT installed is if someone did it manually.
Only if the user does deep upgrades when updating his or her system. I do not, which is how I encountered the problem. When the readline-6 was introduced and the old readline-5 ebuild eliminated from portage, I upgraded only readline-5. This could be considered operator error in that I did not notice that readline-6 was the new SLOT=0.
incorrect ... if they have readline-5:0, then they'll stay there and things will work fine. a PM wont select readline-5:5 as an upgrade over readline-6:0, so i dont think "deep upgrades" are relevant.
If I had done automatic deep upgrades (including slot upgrades), would not have readline-6 been installed as the new SLOT=0, avoid this problem? In other words, isn't readline-6:0 and upgrade over readline-5:0 ? I manually installed readline-5:5 instead, which was my mistake.
right, that's my point. all automatic upgrades should stick with SLOT=0 and thus readline-5:0 became readline-6:0. you manually broke this by moving to readline-5:5 and removing readline-5:0. while we could cause a lot of churn in the tree by forcing people to depend on sys-libs/readline:0, i'd prefer we simply leave it alone since it doesnt appear to be a real issue for people not poking their system directly. and there are plenty of ways to bust up ones system ...
