I confirm the same problem here.

Upgraded from 22.0.99-1.fc7 to:

emacs-22.0.99-2.fc7
emacs-common-22.0.99-2.fc7

I had an emacs symlink before, none now.  Alternatives link is there pointing to
versioned binary:

ls -l /etc/alternatives/emacs
lrwxrwxrwx 1 root root 22 2007-05-15 17:46 /etc/alternatives/emacs ->
/usr/bin/emacs-22.0.99*

Shouldn't these scriptlets be wrapped in conditionals like I see in other
packages that use alternatives?  I think the preuninstall for 22.0.99-1.fc7 is
getting called after the postinstall for 22.0.99-2.fc7, causing the link to be
removed right after it is added.

> rpm -q --scripts emacs
postinstall scriptlet (using /bin/sh):
alternatives --install /usr/bin/emacs emacs /usr/bin/emacs-22.0.99 80

preuninstall scriptlet (using /bin/sh):
alternatives --remove emacs /usr/bin/emacs-22.0.99

E.g. sendmail (trimmed to only the bits that handle alternatives):

postinstall scriptlet (using /bin/sh):
# Set up the alternatives files for MTAs.
/usr/sbin/alternatives --install /usr/sbin/sendmail mta
/usr/sbin/sendmail.sendmail 90 \
        --slave /usr/bin/mailq mta-mailq /usr/bin/mailq.sendmail \
        --slave /usr/bin/newaliases mta-newaliases /usr/bin/newaliases.sendmail \
        --slave /usr/bin/rmail mta-rmail /usr/bin/rmail.sendmail \
        --slave /usr/lib/sendmail mta-sendmail /usr/lib/sendmail.sendmail \
        --slave /etc/pam.d/smtp mta-pam /etc/pam.d/smtp.sendmail \
        --slave /usr/share/man/man8/sendmail.8.gz mta-sendmailman
/usr/share/man/man8/sendmail.sendmail.8.gz \
        --slave /usr/share/man/man1/mailq.1.gz mta-mailqman
/usr/share/man/man1/mailq.sendmail.1.gz \
        --slave /usr/share/man/man1/newaliases.1.gz mta-newaliasesman
/usr/share/man/man1/newaliases.sendmail.1.gz \
        --slave /usr/share/man/man5/aliases.5.gz mta-aliasesman
/usr/share/man/man5/aliases.sendmail.5.gz \
        --initscript sendmail
exit 0

preuninstall scriptlet (using /bin/sh):
if [ $1 = 0 ]; then
        /usr/sbin/alternatives --remove mta /usr/sbin/sendmail.sendmail
fi
exit 0

postuninstall scriptlet (using /bin/sh):
if [ "$1" -ge "1" ]; then
        mta=`readlink /etc/alternatives/mta`
        if [ "$mta" == "/usr/sbin/sendmail.sendmail" ]; then
                /usr/sbin/alternatives --set mta /usr/sbin/sendmail.sendmail
        fi
fi
exit 0

(In reply to comment #2)
> Shouldn't these scriptlets be wrapped in conditionals like I see in other
> packages that use alternatives?  I think the preuninstall for 22.0.99-1.fc7 is
> getting called after the postinstall for 22.0.99-2.fc7, causing the link to be
> removed right after it is added.
> 
> > rpm -q --scripts emacs
> postinstall scriptlet (using /bin/sh):
> alternatives --install /usr/bin/emacs emacs /usr/bin/emacs-22.0.99 80

What happens if you run that command manually?

Chip

I get a /usr/bin/emacs symlink if I run that command manually.

The packages in F7 as it stands don't have the alternatives stuff and that
wouldn't really be appropriate to add at this late stage of the game, so
dropping from F7Blocker as it's not going to block things

I believe I have this fixed in the current devel/ branch.  I'm just waiting for
Jakub's new glibc to hit the buildroots before I do a new build.

Chip

The issue here is arguably a bug in alternatives.  Here's what happens:

The old emacs package installs a symlink in /usr/bin

emacs -> emacs-22.0.95

Then you upgrade the package to emacs-22.0.990.  The scriptlets are run in this
order:

%pre of new package
(package install)
%post of new package
%preun of old package
(removal of old package)
%postun of old package

The %post of emacs-22.0.990 runs while the /usr/bin/emacs symlink still exists,
and in that case, alternatives fails to install its own symlink but nonetheless
returns success!  Then removal of the old package removes the symlink in
/usr/bin/emacs.  I would argue that in this case, alternatives should fail and
therefore the scriptlet would fail also, giving the user a clue that something
has gone awry.

Fundamentally, the issue here is that we are switching from having a symlink
that is not managed by alternatives to having a symlink in the identical
location that is.  IOW, future upgrades of emacs beyond 22.0.990-1 should
maintain this symlink correctly, but the upgrade path from 22.0.95-X to
22.0.990-1 is fraught with danger.

The process works just fine if instead of upgrading emacs, you simply remove the
old package first:

# rpm -e emacs emacs-common

then install

# yum install -y emacs

and you will have the symlink as expected.

Because of the ordering of the scriptlets (new package scriptlets run before old
package scriptlets), it's hard to get this upgrade right.  I'm inclined to close
this bug as WONTFIX and just post the instructions above as a workaround.

Chip

I disagree that this should be closed as WONTFIX.  You shouldn't create pain in
the form of manual upgrade instructions if there is a way to work around the
issue in an automated manner.

You shouldn't be removing the symlink in %preun unless this is the last instance
of the package being removed.  i.e. during package upgrades, %preun shouldn't be
calling alternatives --remove.  The correct way to fix this is to use the same
method that sendmail uses as I quoted above in comment #2:

%preun
if [ $1 = 0 ]; then
        alternatives --remove emacs /usr/bin/emacs-22.0.99
fi
exit 0

The conditional says that if there will be zero instances of this package
installed after the uninstall is completed, then run the alternatives command. 
The condition is only true for removal of the final copy of emacs, not during
upgrades where there will be the new upgraded emacs installed after the
completed transaction.

There is no conditional on the %post script, since there is no harm in running
the alternatives --install multiple times, and this will be necessary to make
sure the symlink gets installed even during upgrades where there might not have
been one previously.

However, if you have a symlink already in place that wasn't installed by
alternatives before, it must be deleted first, as I discovered in this test:

I tested as follows.  First I created a symlink like so:

#ln -snf /usr/bin/emacs-22.0.99 /usr/bin/emacs
#ls -l /usr/bin/emacs
lrwxrwxrwx 1 root root 22 2007-05-22 15:34 /usr/bin/emacs -> /usr/bin/emacs-22.0.99*

Then I reran the alternatives command:

#alternatives --install /usr/bin/emacs emacs /usr/bin/emacs-22.0.99 80

But it didn't overwrite the existing symlink:

#ls -l /usr/bin/emacs
lrwxrwxrwx 1 root root 22 2007-05-22 15:34 /usr/bin/emacs -> 
/usr/bin/emacs-22.0.99*

After deleting the symlink the alternatives command works:

#rm -f /usr/bin/emacs
#alternatives --install /usr/bin/emacs emacs /usr/bin/emacs-22.0.99 80
#ls -l /usr/bin/emacs
lrwxrwxrwx 1 root root 22 2007-05-22 15:34 /usr/bin/emacs -> /usr/bin/emacs-22.0.99*

So %post should end up looking something like this (we don't want the rm -f to
fail and exit the rpm upgrade process, hence the "|| :")

%post
rm -f /usr/bin/emacs || :
alternatives --install /usr/bin/emacs emacs /usr/bin/emacs-22.0.99 80
exit 0

Actually, there may be other issues here since the actual binary name is
versioned.  I'm not aware of any precedent for versioned real binaries being
used with alternatives.  It might be safer to use the method used by sendmail,
calling the real binary after the type of alternative installed:

/usr/bin/emacs.emacs
/usr/bin/emacs.xemacs

etc.

(In reply to comment #8)

> So %post should end up looking something like this (we don't want the rm -f to
> fail and exit the rpm upgrade process, hence the "|| :")
> 
> %post
> rm -f /usr/bin/emacs || :
> alternatives --install /usr/bin/emacs emacs /usr/bin/emacs-22.0.99 80
> exit 0

Wrong!  The %post of the new package above runs *before* the removal of the old
package, which gleefully removes the symlink you just installed.

The problem is that we have to change the scriptlets in the old packages to make
this work smoothly -- and we can't because they are already out there!

Chip

The only hope would be to put something into %posttrans of the new package that
would check to see if the symlink had disappeared and replace it if so.

I was under the impression that this package was going into F7, but it appears
that is not so.  If this problem has only existed in rawhide, and not a released
Fedora, then I would be fine with a manual workaround.  The %post above would
still be necessary for the future packages, though, to guarantee that the
symlink got updated properly on future upgrades.

The current emacs-22.0.95-1.fc7 in rawhide doesn't have any scripts:

# rpm -q --scripts emacs

So the problem in comment #9 won't exist for released versions of Fedora, which
don't have alternatives for /usr/bin/emacs.

(In reply to comment #12)
> The current emacs-22.0.95-1.fc7 in rawhide doesn't have any scripts:
> 
> # rpm -q --scripts emacs
> 
> So the problem in comment #9 won't exist for released versions of Fedora, which
> don't have alternatives for /usr/bin/emacs.

Wrong!  

$ rpm -qlp emacs-22.0.95-1.fc7.x86_64.rpm 
/usr/bin/emacs
/usr/bin/emacs-22.0.95
/usr/bin/emacs-22.0.95-x
/usr/bin/emacs-x
/usr/libexec/emacs
/usr/libexec/emacs/22.0.95
/usr/libexec/emacs/22.0.95/x86_64-redhat-linux-gnu
/usr/share/applications/gnu-emacs.desktop
/usr/share/pixmaps/emacs.png

The old package claims to own the symlink, whereas the new package does not
(it's a side effect of running alternatives in the %post script).  Therefore,
after an upgrade, the symlink will be removed.

Chip

Ok, I concede on that point then.  I see no easy way to fix this.  There may be
a hard way to fix this, in which case I think emacs should not use alternatives
this late in the F7 cycle.  If emacs 22.0.99 will be in F7, it is my opinion
that the alternatives changes should be reverted.

What if /usr/bin/emacs is owned by the new package as a %ghost file?

%files
...
%ghost /usr/bin/emacs

will that prevent the removal problem since the new package will now own the
symlink like the old package did?

Created attachment 155208 [details]
spec patch to implement %ghost /usr/bin/emacs and scriptlet conditionals

I built emacs-22.0.99-2 with this patch and tested the upgrade from
emacs-22.0.95 (pre-alternatives).  The %ghost appears to fix the issue--the
/usr/bin/emacs symlink gets created properly by alternatives and is no longer
erased by rpm during the upgrade transaction.  I tested both emacs and
emacs-nox and also manually changing the alternatives between them.  All
appears to work fine.

(In reply to comment #16)
> Created an attachment (id=155208) [edit]
> spec patch to implement %ghost /usr/bin/emacs and scriptlet conditionals

Looks good; I'll include that in F-8.  It looks like F-7 is going to revert to
the pre-alternatives method for GA.

Thanks-a-million

Chip

emacs-22.1-1.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

The problem definitely persists with emacs-22.1-1.fc8 from rawhide.
'rpm -q --scripts emacs' prints only this:

preuninstall scriptlet (using /bin/sh):
if [ $1 -eq 0 ] ; then
  alternatives --remove emacs /usr/bin/emacs-22.1
fi

and sure enough /usr/bin/emacs does not exist unless created manually;
say with

alternatives --install /usr/bin/emacs emacs /usr/bin/emacs-22.1 80

(Not mentioning that I cannot kill that seriously broken colour on
a backgroud when running with -nw.  An old trick 'emacs -nw -bg none'
does not work anymore.  Well, not entirely true.  I can run
'emacs -nw --color=no' but that is somewhat overdoing things.)

(In reply to comment #19)
> The problem definitely persists with emacs-22.1-1.fc8 from rawhide.
> 'rpm -q --scripts emacs' prints only this:
> 
> preuninstall scriptlet (using /bin/sh):
> if [ $1 -eq 0 ] ; then
>   alternatives --remove emacs /usr/bin/emacs-22.1
> fi

File a bug against rpm, then, because it is not reporting the %posttrans
scriptlet that does the alternatives install.

> and sure enough /usr/bin/emacs does not exist unless created manually;

Remove the old package, then do a fresh install of the new one and report the
results here, please.

Chip

We had this solved with the %ghost /usr/bin/emacs.  Why did you decide to change
to %posttrans?

emacs-22.1-1.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

FWIW, xemacs had the same problem back when I switched it to use alternatives,
IMO it is indeed a bug in alternatives (#104940) and only in the Red Hat/Fedora
one (IIRC it doesn't exist in the original implementation in Debian).

The fix in Comment #22 works for me.  The reason it didn't work initially, is
because of the existing testing package I had installed.  Starting from the last
official release of emacs and upgrading to 22.1-1.fc7 works properly with the
symlink.

I am seeing this again after a preupgrade from Fedora 14 to 15.

Revisiting this in the context of another package, it seems to me
that a newly %ghost'ed file keeps the original file on disk which
prevents alternatives from creating the new symlink.

Adding %pre logic to remove any existing file seems to be
a workaround, but I agree that alternatives/rpm could
handle this better.