after setting up a more rigorous (at least i think) testing methodology for myself i discovered a few problems with parted's ebuild. The main issue is the common test for a use flag. Either: if [ "`use readline`" ] then myconf="${myconf} --enable-readline fi (which appeared in parted's ebuild) or alternatively use readline && myconf="${myconf} --enable-readline" These two statements are broken for the case where --enable-readline is the default for the package (as is the case for parted). ie. if "use readline" evals false (ie. user does NOT request readlinein USE), then no myconf is set and ./configure runs with the default --with-readline. Thus the user gets readline support either way -- which is wrong. The correct (and more robust) way to do it is to use a ternary if/then/else so the outcome is independent of the default configure settings. I know parted is probably not the only package which makes this mistake, so I'm going to go through portage looking for the same pattern. The other main problem i saw in parted's ebuild was related to gettext. -r2 lists "nls? ( >=sys-devel/gettext-0.10.38 )" as a dependency. But parted doesn't care about what gettext version is installed on the system -- parted has it's own built-in gettext which is uses regardless of --with/without-included-gettext. -r2 just assumes parted's configure will use the system's gettext. In the patch I changed the nls dep to "nls? ()" since it is still possible to configure parted's nls support even though it doesn't depend on system getttext. I know parted is probably not the only package which makes these mistakes, so I'm going to go through portage looking for the same patterns. Anyway. Enough of rant, here's the patch.
Created attachment 445 [details, diff] parted-1.4.24-r2-1.4.24-r3.patch * fixed crazy python dependency (no such thing required to build or run parted) * fixed nls? dep. for builtin case * added missing documentation items * fixed broken/naive checks for readline (and nls) use flags * updated other dep versions it's a sys-app though...
lol, I am shy of sys-apps at the moment as well. as a preliminary comment, I would say that the "nls? ()" in the DEPENDS section is superfluous,since DEPENDS are for packages that _need_ to be emerged and present on the system in order to even think about compiling. Similarly, RDEPENDS are what need to be emerged and present to run the package after a successful compile. so with "nls? ()" you check for nls in USE, and emerge nothing as a dependency. Especially in this case, where gettext is built-in regardless, the nls check in src_compile() will do just fine on its own.
Nice fix, and the idea should probably be instituted on all the ebuilds like this. Thanks again :)
