This warning clutters my output, and the web: /usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted definition of AC_CHECK_LIBREISERFS /usr/share/aclocal/progsreiserfs.m4:13: run info '(automake)Extending aclocal' /usr/share/aclocal/progsreiserfs.m4:13: or see http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal see the archlinux URL in reference
there a reason we haven't just killed progsreiserfs ?
vapier: If you think it can die now, please rip it out.
+ 19 Nov 2012; Samuli Suominen <ssuominen@gentoo.org> + progsreiserfs-0.3.1_rc8.ebuild, + +files/progsreiserfs-0.3.1_rc8-autotools.patch: + USE="static-libs" and use prune_libtool_files from eutils.eclass. Fix + underquoting within progsreiserfs.m4 wrt #442226 by Raphaël Droz If you still want to remove the package, that is fine by me, but I recall there was things this package can do, what reiserfsprogs can't, just not the details...
(no revbump because this is so minor issue)
*** Bug 221079 has been marked as a duplicate of this bug. ***
I ran into this bug trying to compile mysql-workbench-6.3.4-r1: /usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted definition of AC_CHECK_LIBREISERFS /usr/share/aclocal/progsreiserfs.m4:13: run info Automake 'Extending aclocal' /usr/share/aclocal/progsreiserfs.m4:13: or see http://www.gnu.org/software/automake/manual/automake.html#Extending-aclocal Doing a search to find the package that owns the problematic .m4 file: equery belongs /usr/share/aclocal/progsreiserfs.m4 revealed: * Searching for /usr/share/aclocal/progsreiserfs.m4 ... sys-fs/progsreiserfs-0.3.1_rc8 (/usr/share/aclocal/progsreiserfs.m4) This package was installed in 2007 *and has not been updated since!*: eix sys-fs/progsreiserfs [I] sys-fs/progsreiserfs Available versions: 0.3.1_rc8 {debug examples nls static-libs} Installed versions: 0.3.1_rc8(05:25:54 am 30/03/2007)(nls -debug) Homepage: http://reiserfs.linux.kiev.ua/ Description: Library for accessing and manipulating reiserfs partitions and, following the advice in https://forums.gentoo.org/viewtopic-t-365609-highlight-share+aclocal+pathdps+m4+172+pathdps+m4+exist.html I removed it with: emerge --depclean --ask sys-fs/progsreiserfs I was going to file a bug report, when I found this thread. Two things about it, even though the subject is so 'minor': a) The issue was resolved, BUT THE VERSION NUMBER WAS NOT INCREMENTED! This led me to think the ebuild was outdated and I threw it away. If the version had been incremented, the package would have been updated during my numerous updates...Now I will have to re-merge it. :-( b) The package IS somehow useful, even though no package depends on it... HOW CAN THAT BE? This means that all ebuilds that use it are currently *buggy* - in the sense that they are missing a dependency! BOTH a) AND b) ARE TOTALLY CONTRARY TO COMMON SENSE! Either an ebuild was changed, or it was not. I *must* trust the version number as an indicator of change! Otherwise, each time I encounter a problem for which I cannot think of a solution, I will have to 'emerge -C ...', then re-merge, because - who knows? - maybe the ebuild was updated, but the version number was not - what is the difference, then to the clueless answers ones gets to all Windows problems everywhere from clueless. helpless users - "uninstall, then reinstall - that solved it for me", "wipe-out, then re-install Windows, this somehow solves the problem"...? Either a package is *needed*, or it is NOT needed! If it is needed by some other package, that other package must include it in its DEPEND and/or RDEPEND variable! If it does not, it's ebuild is missing a dependency - which runs contrary to the whole idea of portage. Now each time 'emerge --depclean' tells me there are no packages that need package X, I will have to think "well, let's keep it around, maybe some packages DO need it, even though they don't say it - remember what was said for progsreiserfs in that bug thread?" I cannot work this way! I will never move on, if I have to accomodate BOTH sides of the argument! Please change your logic!
Looking at https://bugs.gentoo.org/show_bug.cgi?id=77210#c2 I can at least partially resolve my problem b) above and answer the related question 'can we kill progsreiserfs safely' with a sure 'no': parted and testdisk are named as candidates that use progsreiserfs in that comment. I had parted installed, but not testdisk. 'emerge --depclean progsreiserfs' did not bring up any package that depends on progsreiserfs. That's correct, because parted does not use progsreiserfs (anymore?): ldd /usr/sbin/parted linux-gate.so.1 (0xXXX) libparted.so.2 => /usr/lib/libparted.so.2 (0xXXX) libreadline.so.6 => /lib/libreadline.so.6 (0xXXX) libncurses.so.5 => /lib/libncurses.so.5 (0xXXX) libc.so.6 => /lib/libc.so.6 (0xXXX) libuuid.so.1 => /lib/libuuid.so.1 (0xXXX) libdl.so.2 => /lib/libdl.so.2 (0xXXX) libblkid.so.1 => /lib/libblkid.so.1 (0xXXX) /lib/ld-linux.so.2 (0xXXX) (the 'XXX's are mine). Now I installed testdisk, after remerging progsreiserfs. testdisk does need progsreiserfs: ldd /usr/bin/testdisk linux-gate.so.1 (0xXXX) libncursesw.so.5 => /lib/libncursesw.so.5 (0xXXX) libreiserfs-0.3.so.0 => /usr/lib/libreiserfs-0.3.so.0 (0xXXX) ... and /usr/lib/libreiserfs-0.3.so.0 belongs to progsreiserfs: equery files progsreiserfs | grep libreiserfs-0.3.so.0 /usr/lib/libreiserfs-0.3.so.0 /usr/lib/libreiserfs-0.3.so.0.0.1 and testdisk includes progsreiserfs in its dependencies: qdepends -CQ progsreiserfs app-admin/testdisk-7.0-r3 So you can't 'kill' progsreiserfs from Gentoo because it is needed by at least testdisk (which is a very important package, but I hope you will *never* need it...). AND: the ebuilds that need progsreiserfs do seem to include it in their dependency lists, at least testdisk does, parted does not seem to need it. a) is still problematic for me though...
