There is a problem with GNU Info file installation of Emacs and the way Portage handles Info "dir" files. Let me first describe the current behaviour of both, and what we currently have implemented as workaround in ebuilds: Emacs ebuilds install their Info files in subdirectories /usr/share/info/emacs-${SLOT}. The upstream package contains a pre-made "dir" file with specific ordering of menu entries. No other package will install any Info file in this Emacs specific directory (so normally the "dir" file can be static). One of the Info dirs is later added to INFOPATH by the Emacs eselect module, by setting the variable in /etc/env.d/50emacs. Portage (in "prepinfo") compresses all files in /usr/share/info and its subdirectories (a wanted feature), but also removes the "dir" files from all subdirs. Later the "dir" files are regenerated, but only in the subdirs that are listed in INFOPATH. So at this point any /usr/share/info/emacs-${SLOT} directory may: a) not contain a "dir" file at all (if the subdir was not in INFOPATH), or b) contain a regenerated "dir" where the original ordering of entries is lost. Our current workaround in app-editors/emacs is to call a function "emacs-infodir-rebuild" from pkg_post{inst,rm} that will regenerate the dir file, in order to avoid case a) at least. However, this leaves us with two problems: - Upstream's ordering of menu entries is lost. - The "dir" file is an orphan that is not owned by the installed Emacs package. I don't see any way how we could solve the problem at the ebuild level (please correct me if I'm missing something). So, would it be somehow be possible to tell Portage "don't ever touch this dir file"?
A possible solution would be use an (empty) .keepinfodir file as a marker that tells portage that the dir file should be left alone. AFAICS, a test for this would then be needed in prepinfo and in chk_updated_info_files.
Created attachment 245890 [details, diff] Patch that is implementing the functionality
(In reply to comment #2) > Created an attachment (id=245890) [details] I think the reason that keepdir() uses a filename pattern like .keep_${CATEGORY}_${PN}-${SLOT} is to avoid file collisions, and it's handy to be able to see owners of the '.keep' files in the filenames (and makes the reference count plain to see). Should we do the same for '.keepinfodir' files?
(In reply to comment #3) > I think the reason that keepdir() uses a filename pattern like > .keep_${CATEGORY}_${PN}-${SLOT} is to avoid file collisions, I don't think that this is an issue here: - In cases where the ".keepinfodir" files would collide, already the "dir" files would collide. - Keeping the Info dir file makes no sense in directories where more than one package will install Info files. > and it's handy to be able to see owners of the '.keep' files in the > filenames (and makes the reference count plain to see). > Should we do the same for '.keepinfodir' files? Do we need a special command ("keepinfodir"? "skipinfodir"?) for creating the file if we use such a complicated filename pattern?
(In reply to comment #4) > Do we need a special command ("keepinfodir"? "skipinfodir"?) for creating the > file if we use such a complicated filename pattern? Well now that you mention it, I notice there isn't one. I guess the alternative is for ebuilds to be aware of the '.keepinfodir' concept and to create them manually? Maybe there's some other obvious way that I've missed?
Created attachment 246057 [details, diff] Updated patch, accepting any file matching .keepinfodir*
(In reply to comment #6) > Created an attachment (id=246057) [details] > Updated patch, accepting any file matching .keepinfodir* That looks good to me.
That has been included in portage-2.1.9.1. Can this bug be closed?
Yes, it's fixed now.
