Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 173456 - emacs-cvs and new slots (wrong info-dir and stale symlinks)
Summary: emacs-cvs and new slots (wrong info-dir and stale symlinks)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Emacs project
URL:
Whiteboard: Emacs Overlay
Keywords: InOverlay
Depends on:
Blocks:
 
Reported: 2007-04-05 11:48 UTC by Martin Väth
Modified: 2007-04-17 06:12 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Väth 2007-04-05 11:48:46 UTC
Whenever a new emacs-cvs slot appears, I run into two troubles which I fix manually but which perhaps might be fixed in the ebuild:

1. At the first install the /usr/share/info/emacs-${NEWSLOT} is not treated correctly by portage (e.g. */dir is bzipped). The reason is that at the first install the new /usr/share/info/emacs-${NEWSLOT} is not yet contained in the INFOPATH environment variable when the new ebuild is installed. My workaround currently is to create an appropriate /etc/env.d/50emacs-cvs-${NEWSLOT} manually (and to call env-update to fix INFOPATH) *before* emerging the new slot, but this is obviously hackish. Maybe a solution would be to export an appropriate INFOPATH within the ebuild (although I haven't tried whether portage accepts such a "late" change of the environment in this case - if not, this might need to be a feature request for portage).

2. When deleting the old slot in advance, there are a lot of warnings about stale symlinks not being deleted. I do not understand the reason for this: The symlinks are dead because they pointed to the just deleted emacs; so why leave the rubbish on the disk? (Even if the user plans to install a new slot immediately afterwards, he has to clean up manually if he wants to be sure to have a "clean" disk, because the new slot might perhaps use less/different symlinks.)
Comment 1 Ulrich Müller gentoo-dev 2007-04-05 14:06:24 UTC
Hi, these issues have already been addressed in the Emacs overlay.

Ad 1) Info dir: is now rebuilt in pkg_postinst. The INFOPATH (i.e. the env.d file) is controlled by an eselect module.

Ad 2) The symlinks should be handled by the new eselect module, too.

In general, SLOTting has also been reconsidered. There will be only one slot for each Emacs major version.
Comment 2 Christian Faulhammer (RETIRED) gentoo-dev 2007-04-05 14:23:09 UTC
So we will close this bug once the ebuilds from the overlay will be transferred to Portage.  This will likely be in about two weeks when I have finished my exams and am back from a short trip.
Martin, go and try the Emacs overlay, report any problems by bugzilla or email.
Comment 3 Martin Väth 2007-04-05 20:46:15 UTC
Thanks, I was not aware about the emacs overlay. Indeed, it solves all issues, and the new slotting scheme has my vote. :)

Please add also KEYWORDS='~amd64' to emacs-cvs and its new dependencies eselect-emacs and emacs-desktop when you transfer it to the tree - so far, it works great here on all of my 64 and 32 bit systems.
Comment 4 Christian Faulhammer (RETIRED) gentoo-dev 2007-04-06 09:48:52 UTC
(In reply to comment #3)
> Thanks, I was not aware about the emacs overlay. Indeed, it solves all issues,
> and the new slotting scheme has my vote. :)

 It has some advantages.
 
> Please add also KEYWORDS='~amd64' to emacs-cvs and its new dependencies
> eselect-emacs and emacs-desktop when you transfer it to the tree - so far, it
> works great here on all of my 64 and 32 bit systems.

 This must be done by the architecture teams, I try to get access to a remote amd64 system and keyword it then.
Comment 5 Ulrich Müller gentoo-dev 2007-04-17 06:12:16 UTC
Fixed in 22.0.98, 22.0.9999-r10, and 23.0.0-r6, thanks for reporting.

(Keywording for ~amd64 will follow soon.)