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

[Harold L Hunt II]

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.
> 
> 
> Touché.  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?

>>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 :)

>>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.

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.

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.

How does that sound?

>>>XFree86-lib.sh: mkdir, test?, tar, rm, ln
>>>XFree86-prog.sh: touch, ln
>>>XFree86-xserv.sh: ln
>>>fontconfig.sh: dirname, basename, diff, cp, mkdir
>>>      Note: this one also uses bash syntax.  Moreover, it requires things
>>>      like "diff" and "dirname"/"basename" to run, but neither "diffutils"
>>>      nor "sh-utils" are in the "requires" clause of "fontconfig".
>>>freetype2.sh: mkdir, ln
>>
>>I agree that I should probably hand-craft the PATH for all of the above
>>scripts (including the XFree86-f*.sh scripts).
> 
> 
> Yeah, you're right, actually prepending /bin to the path might be a better
> solution for large scripts.  But what I don't understand is why it didn't
> work when done from setup...  Could it be an environment export issue of
> some sort?
> 
> 
>>>xfig.sh: mkdir, tar, rm, ln
>>>      Note: "tar" should be "require"d.
>>
>>Ditto.  Interesting not about tar not being a required package.  I never
>>realized that that script used tar.  In fact, I don't remember writing
>>it, so somebody else must have written it... clever script :)
>>
>>Harold
> 
> 
> Yep, that's the best (easiest) way to copy a directory structure with
> symbolic links, etc, intact.

I'm updating the xfig setup.hint files right now.  I am also fixing the 
longstanding issue of depending upon ghostscript instead of 
'ghostscript-x11 ghostscript-base'.  This has caused numerous compliants 
about being unable to export figures correctly from xfig.

Harold