Two offenders; toolchain.eclass, and gcc-3.2.3-r4. All of that looks to be working around gcc installing info files to /usr/share/gcc-data/<target>/<gcc-version>/info/ . The problem here is that the eclass is relying on functionality outside of PMS. Question is, how do we solve this?
the usage is harmless for people who don't have prepinfo (other than a "command not found" warning). if $D was scanned for info dirs like we do for man dirs, then gcc wouldn't need it.
In EAPI 4 it will fail as well, because prepinfo and prepman are essentially a no-op there. But you could just do: docompress /usr/share/gcc-data/<target>/<gcc-version>/info/ docompress -x /usr/share/gcc-data/<target>/<gcc-version>/info/dir
I don't know what the PMS team should do here. The problem has been addressed in EAPI 4, and there's nothing that we can do for earlier EAPIs.
(In reply to comment #2) > In EAPI 4 it will fail as well, because prepinfo and prepman are essentially > a no-op there. But you could just do: > > docompress /usr/share/gcc-data/<target>/<gcc-version>/info/ > docompress -x /usr/share/gcc-data/<target>/<gcc-version>/info/dir Doesn't run info's index generation, which is one of the main reasons they're invoking it. At this point, from a quick scan of pms info pages don't even look covered, so that's an area that needs expansion (ebuilds have relied on it for a long while)...
(In reply to comment #4) > Doesn't run info's index generation, which is one of the main reasons > they're invoking it. It doesn't need to, because a) upstream's build system installs a dir/index file already (see $(DESTDIR)$(infodir)/%.info rule in gcc/Makefile.in), and b) Portage will eventually regenerate all dir files in INFOPATH (see function chk_updated_info_files). Alternatively, if the ebuild/eclass really wants to rebuild it itself, it's also not complicated (code snippet from pkg_preinst of emacs-23.4-r1.ebuild): rm -f "${ED}"${infodir}/dir{,.*} for f in "${ED}"${infodir}/*; do if [[ ${f##*/} != *-[0-9]* && -e ${f} ]]; then install-info --info-dir="${ED}"${infodir} "${f}" \ || die "install-info failed" fi done > At this point, from a quick scan of pms info pages don't even look covered, > so that's an area that needs expansion (ebuilds have relied on it for a long > while)... Please, not again this discussion. There even was a council decision (2009-02-12 meeting) that confirmed that prep* are internal functions of the package manager and should be avoided in ebuilds. PMS mentions it in section 12.3.3.15 (in the eapi-4-approved version) as "reserved for package manager use and may not be used or relied upon by ebuilds".
(In reply to comment #5) and we specifically do *not* rely on upstream's build system setting up the index files correctly because it's unreliable, especially when installing files by hand or doing fix-ups after the `make install` finishes. Brian isn't talking about adding prep* funcs to the spec, but of documenting a way to make it unnecessary. manually fixing things up is *not* a solution -- portage does this implicitly for all packages, and the only reason gcc does it manually is because of installing into unique paths.
The only thing that prepinfo does (besides queueing the directory up for compression) is that it _removes_ the index ("dir") file. This needs to be done, because otherwise the dir file being merged from D could collide with one already present in ROOT. Regeneration of the index isn't done by prepinfo, but will only take place at the end of the emerge command.
(In reply to comment #7) > The only thing that prepinfo does (besides queueing the directory up for > compression) is that it _removes_ the index ("dir") file. This needs to be > done, because otherwise the dir file being merged from D could collide with > one already present in ROOT. > > Regeneration of the index isn't done by prepinfo, but will only take place > at the end of the emerge command. The point was to try and get it registered in some fashion w/ the PM; among other things, so the PM doesn't keep orphaning the generated index (and/or does simple things like *wiping* the index from ${D} to prevent such collisions). The PM logic for regenerating the index is limited to paths in INFOPATH (which may not cover all actual INFO paths- just what is globally the norm).
In directories like /usr/share/info where the index covers several packages there's no other way than having an orphaned file for it. Are the Info directories of gcc, binutils, etc. uniquely used by the respective package? Or are they shared between several packages (or slots), too?
(In reply to comment #9) > In directories like /usr/share/info where the index covers several packages > there's no other way than having an orphaned file for it. If the PM knows where index's are supposed to be (or were requested at a one point), it can track those locations pruning/removing as necessary. > Are the Info directories of gcc, binutils, etc. uniquely used by the > respective package? Or are they shared between several packages (or slots), > too? In gcc's case, afaik it's uniquely controlled by them (they have their own dir).
If /usr/share/info is the only directory where the index is shared amongst packages, then I see no need for a new mechanism to register or track these locations. Packages using a unique info directory could be modified such that the index file will not be orphaned, but belong to the installed package. This probably means that it should be regenerated in src_install or pkg_preinst.
(In reply to comment #11) > If /usr/share/info is the only directory where the index is shared amongst > packages, then I see no need for a new mechanism to register or track these > locations. Dude: INFOPATH. Arbitary location, same sort of behaviour as MANPATH. > Packages using a unique info directory could be modified such that the index > file will not be orphaned, but belong to the installed package. This > probably means that it should be regenerated in src_install or pkg_preinst. Leaving devs up shit creek should multiple packages use the same space...
$ find /var/db/repos/gentoo \( -name '*.ebuild' -o -name '*.eclass' \) -exec grep prepinfo {} + $ Closing.
