More: [1.7] packaging problem? Both /usr/bin/ and /usr/lib/ are non-empty

[Earnie Boyd]

Quoting Corinna Vinschen <corinna-cygwin@cygwin.com>:

> On May  6 15:14, Dave Korn wrote:
>> Corinna Vinschen wrote:
>> > On May  6 14:14, Dave Korn wrote:
>> >> Corinna Vinschen wrote:
>> >>> On May  5 18:41, Earnie Boyd wrote:
>> >>>> I would make / permanent; i.e. unchangeable by the user.  Any mounts in
>> >>>> /etc/fstab to / are just discarded.  For MSYS the root / is always the
>> >>>> parent directory of the directory containing the dll and the directory
>> >>>> containing the dll is always /bin.
>> >>> Hmm, that's an idea.  We never fixed root before but there is a certain
>> >>> dumbness to the idea to change / (and /usr/bin) away from the place
>> >>> where the Cygwin DLL resides.
>> >>>
>> >>> I'd rather like to hear other opinions before doing that, though.
>> >>   Just one question: how will this interact with chroot()?
>> >
>> > This only happens when started the first time.  At the time the home dir
>> > is evaluated a potential chroot is not set up.  So it won't be any
>> > different than without chroot.
>>
>>   Homedir?  I thought that was the other thread!
>
> Oops :}
>
>>     No, I meant 'if we "make /
>> permanent; i.e. unchangeable by the user", will chroot still  
>> work?', or to put
>> it another way, I'm asking "are you proposing to remove the  
>> functionality that
>> allows reassigning "/" or just ignore it in the code that parses fstab, or
>> block it at the level of the mount() system call?"
>
> I'm not proposing it, Earnie is ;)  From my POV, it might be a viable
> option.  If we would do it, it wouldn't affect chroot because the code
> is only run once at the start of the first Cygwin process in a user
> session.  A call to chroot would work as usual.
>

All else seems silent on the proposal.  You might want to give it a go.

--
Earnie