This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Corinna wrote:
> ...but here's the problem.  Consider these default entries:
>
>   C:/cygwin /
>   C:/cygwin/bin /usr/bin
>   C:/cygwin/lib /usr/lib
>
> And /etc/fstab only consists of a single line:
>
>   X:/cygwin-1.7 /
>
> then, after reading /etc/fstab we have the end result:
>
>  X:/cygwin-1.7 /
>  C:/cygwin/bin /usr/bin
>  C:/cygwin/lib /usr/lib
>
> That looks somewhat fragile, doesn't it?

I was toying with the following idea:

1) It is invalid to have drive "letters" that aren't letters.  So,
0:/cygwin/bin is not a valid path.
2) What if /etc/fstab supported the following construct:

X:/cygwin /
0:/cygwin/bin /usr/bin
0:/cygwin/lib /usr/lib

where "0" (zero) means "whatever drive / is mounted from".  So, suppose
that the default entries are expressed using this new syntax (all three
of them):

0:/cygwin /
0:/cygwin/bin /usr/bin
0:/cygwin/lib /usr/lib

This "default" construct would lead to the following behavior:
a) figure out where / is using the current algorithm -- which may be
"find module dir for cygwin1.dll, go ../etc/fstab and goto step b"
b) read the /etc/fstab if it exists (may override any of these default
settings)
c) given the (now possibly modified in-memory copy of "fstab"), replace
all "0:" drive specs 
   in the with the drive letter from the / mount

Then, in your scenario (real fstab that has only an entry for
X:/cygwin), you'd have

X:/cygwin /
X:/cygwin/bin /usr/bin
X:/cygwin/lib /usr/lib

But, any of them can still be overridden using explicit lines in a
"real" fstab.

--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]