Re: installation problem: no /etc/profile

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Wed, Mar 07, 2007 at 06:19:38AM -0700, Eric Blake wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Redirecting to cygwin-apps, since this is a setup.exe issue.  And sorry
>for the delayed reply; this arrived back when I was on vacation, and I'm
>still trying to plow through my inbox.
>
>According to Mark Peloquin on 2/18/2007 2:47 AM:
>> I recently installed cygwin with some problems.  This is the fourth
>> installation of Windows where I have installed cygwin, and this has
>> happened with this Windows installation twice now.  I don't think it's
>> a fluke.  My guess is that it is only noticeable for new
>> installations.
>
>Only noticeable for new installations, and dependent on the order in which
>setup.exe runs postinstall scripts; bash's postinstall MUST run before any
>other postinstall that uses /bin/sh.  Which version of setup.exe are you
>using?
>
>I know that older setup.exe were broken, and merely executed all scripts
>in alphabetical order, so older releases of bash provided the postinstall
>as 00bash.sh so it would run first.  But I thought that setup.exe had been
>changed to execute in dependency order (for example, base-files depends on
>bash, so base-files' postinstall scripts should not be attempted until
>after bash), so in bash-3.2.9-11 I renamed the postinstall to plain
>bash.sh (partly because I converted to cygport, and couldn't figure out
>how to make cygport keep the name 00bash.sh).
>
>Maybe what I should do is upload a new package along the lines of
>00run_me_first belonging to the admin category _PostInstallFirst
>(mirroring the existing admin category of _PostInstallLast that is
>normally hidden from view), and by having bash depend on that, I can
>reinsert a postinstall script that will run early enough in new
>installations to allow installing packages such as aalib, automake, and
>base-files?  But it would really be nice to know first of all whether this
>is fixed in setup.exe; and if the fix is only in a setup.exe snapshot, we
>could really use a release of setup.exe.

This probably goes without saying but if you do that, please test your
assumptions about how this would work with setup.exe before it goes live.

cgf