Heads-up: postinstall scripts and PATH (Attn all package maintainers)

[Igor Pechtchanski]

Harold,

On Tue, 24 Feb 2004, Harold L Hunt II wrote:

> Igor,
>
> Igor Pechtchanski wrote:
>
> > On Tue, 24 Feb 2004, Harold L Hunt II wrote:
> >
> >>Igor Pechtchanski wrote:
> >>
> >>>XFree86-f*.sh: umount, cygpath, mount
> >>>      Note: the above script should also check that the directory is
> >>>      already mounted in the correct mode instead of unmounting and
> >>>      remounting it all the time.
> >>
> >>The reason we force an unmount is that the mount point may, in fact, by
> >>pointing to a non-existant path.
> >
> > Touche.  Make that "...already mounted off the correct path and in the
> > correct mode...".
>
> I'm not sure if it would be easy to test that the path pointed to by a
> mount is valid and writable?  Do you know of a clean way to do it?

Umm, why not just test "[ -w /usr/X11R6/lib/X11/fonts ]"?  But as for
checking that it's mounted in binary mode, I can't think of a good way to
do this other than parse the output of mount, and in this case you're
probably better off forcing a umount and remounting.

> >>That means that setup.exe will extract our package files to /dev/null on
> >>an attempt at a first install with an invalid font mount point.
> >>However, most users will then attempt a second install; without the
> >>forced unmount/remount, the same problem would recur.  The forced
> >>unmount/remount causes the second and subsequent installation attempts
> >>to succeed.
> >
> > OTOH, it's probably not that expensive to do anyway, so it might as well
> > stay that way (especially since I was the one who originally suggested it)
> > ;-)
>
> Yeah, it was a good idea :)

Thanks.

> >>I would love to solve this problem properly but "pre-install" scripts
> >>would be a real challenge for setup.exe, unless there was a concise set
> >>of rules about what packages could and could not have pre-install
> >>scripts, lest we end up with chicken before egg problems for some packages.
> >
> > Yes.  Setup does support "preremove" scripts, though, and they could do
> > the umount...  It might be cheaper to do it the way it's done now, but if
> > done in the preremove, at least the installation should succeed.
>
> Preremove scripts are from the previous installation of a package,
> correct?  In other words, if you have foo-1.0 installed and you try to
> install foo-1.1, the preremove will be from foo-1.0, not from foo-1.1,
> right?  If that is the case, then this won't help like a preinstall
> script would.  See, most people that have reported this problem just
> delete the cygwin tree on their drive, which prevents any preremove
> scripts from being run, so that script would never run to fix the fonts
> mount point before the next unpacking of the fonts tarballs.

Ah, you're right.  Maybe it's time for a "Cygwin uninstall" utility...

> Maybe the proper fix is to have setup.exe check if it is about to untar
> something into the ether.  It is just amazing that you can have a stale
> mount point that causes a package to not be extracted correctly, yet
> setup.exe doesn't report that the installation failed at all.

A stale mount point can do more than that...  I once deleted half of my
/usr/share because of an attempt to "rm -rf" a stale mount point...

> On the other hand, this may be a difficult fix, since we can't cull
> mount points that the user has setup because they may be for a network
> drive and they are simply not on the correct network at the time.  Maybe
> we could temporarily prune any mounts that are invalid at the time,
> without changing the user's mount settings in the registry.  That way
> the package would be unpacked somewhere, and our postinstall script
> would come along later and fix the mount point for /usr/X11R6/lib/fonts.

Umm, wouldn't this mean that the new fonts will end up at some random
place?  And that once the users reconnects to the network, they'll see the
old fonts?  Maybe setup should just fail...  Or let the user know that the
mount is stale and interactively do something with it...

> How does that sound?

Frankly, I don't really see a good solution here.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton