[Proposal] Moving user mount information to HKLM
Problem:
The mount -u command fails if a domain user's registry hive is not
downloaded from the domain controller and no local hive cache exists.
Solution:
Change cygwin1.dll/mount to
1. store mount information under HKLM/CYGWIN/MOUNTS/{USER-SID}, or
2. let mount succeed without persisting the mount info, by updating the
in-memory data structures and maybe issuing a warning about the missing user
hive.
I can submit patches for either solutions if needed. Solution 1 is more
intrusive since it changes the way existing user mounts are stored.
As an aside, this seems to be the solution used by SFU30 to store user
specific mounts/other info.
3. Mounting all mounts as system is not an option since there's a limit of
the amount of mounts.
Background:
We set up a Windows compile server for 20-30 developers logging in with
their domain user credentials via ssh with password. Since no domain user
has ever interactively logged in, no registry hive exists for the
authenticated user, and the mount code in cygwin1.dll will return an error
when trying to mount a user partition.
We're only interested in a temporary mount of /home/$USER for the duration
of the login session, and would appreciate being able to do so.
Our current workaround involves symlinks, but this creates problems since
`pwd` != /bin/pwd:
dan~>ssh server_without_my_hive
Password:...
[Fanfare]
# /etc/profile runs "net use H: "
# and creates a link /home/dan.lnk -> /cygdrive/h
dan~> pwd
/home/dan
dan~> /bin/pwd
/cygdrive/h
We've had to modify lots of scripts to work around this issue, and it would
certainly be nice not to have to.
Thanks,
Dan
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
[Proposal] Moving user mount information to HKLM
This is in reply to Christopher Faylor's message http://cygwin.com/ml/cygwin/2002-09/msg01428.html. I hope it will show up correctly in the mail list. > .. I expect that, as time progresses, there will be more checks to > ensure that doesn't happen. 1.3.13 has new checks for this, in fact. This makes sense only if RH views Cygwin as an Microsoft Windows OS UNIX extension and not as a standalone UNIX emulator or VM running on top of Windows. > You don't install two versions of linux on your system and expect them to> interoperate at the same time. Ditto, cygwin.It is like comparing apples with oranges. I have not seen yet Linux running directly on top of a win32 host, nontheless cygwin running naked without a win32 host. Everybody who read the code knows that a debug cygwin1.dll or regular one built for a different shared memory and registry can coexist with other versions. What's wrong in having the latest 'stable' version of Cygwin and also experimenting with the latest net release installed on the same computer. One can use the stable one and switch to the most recent one when percieved as stable. Or get back to the version on which things where working fine. It is all about freedom. Why to deliberately restrict this? Please let me know if there are any technical issues I am not aware of.Thank you,Doru Carastan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[Proposal] Moving user mount information to HKLM
This is in reply to Christopher Faylor's post http://cygwin.com/ml/cygwin/2002-09/msg01430.html > I am trying to set the mind set here. As the person responsible for cygwin > development, that's how we are progressing. I totally agree and apreciate the openness. > Actually, it doesn't work all that well, even in this context. We have a > problem with this RIGHT NOW, in fact. Getting this working reliably is > a constant battle. It was actually quite broken for months. It's only > a little broken now. Obviously I missed some technical problems. I managed to create an rpm based setup environment for win32 and it worked without too much problems using the 1.3.4 version. I mean without interfering with an installed cygwin of a different version (1.37, 1.3.9, 1.3.12). Please be assured that I understand very well your position. I am in the same battle at work. > Because getting it working reliably is hard and having two versions of the > DLL on the system is a technical support nightmare. You obviously are not > reading the cygwin mailing list. Agreed. And I do read every message on the 'cygwin' mail list. I have been doing it for more than 2 years. I do not want you to think I am sombody who just complain and do not understand your work. Myself and others probably are in the position to write applications or port some open source tools on Cygwin and try to distribute them within the GNU licensing limits. In my case I am almost done with a way to use rpm on win32 and UNIX (Solaris, Linux, etc) as part of a crossplatform solution. And that is without using or interfering with a possible rpm installation on UNIX or an existing Cygwin on windoze. I got rpm 4.0.2 and I got an old cygwin 1.3.7 doing it. Now I hear that this doesn't work no more. If it is for a good reason than my bet was wrong. It happens all the time. This leaves me only one option. To install/upgrade Cygwin on the users computer. It is a hard task. Very hard one considering so many things that can go wrong. With this in mind I will like you to consider publishing in the Cygwin FAQ the guidlines one should use for distributing an (open source) application outside the official net release. I believe it is an important topic in the spirit of 'getting our minds set'. Personally I am thinking of using the setup tool to install the packages that creates the environment used to build the application and add the extra application package(s) to setup.ini. The user will be forced, but ultimately it will be his/her choice, to upgrade/downgrade to the version required by the application. It will also be my problem when a new Cygwin breaks the application. This will require me, as a vendor, to either distribute a new version every time a new Cygwin breaks the binary compatibility or have the user recompile the application that relies on Cygwin. I am sure you see this in a broader perspective. Thank you, Doru Carastan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [Proposal] Moving user mount information to HKLM
How about breaking free from using the windoze registry. There is absolutely no special need to use it IMO. All the mount info can be stored in a plain ASCII file like 'cygwin.cfg'. As part of its initialization the cygwin1.dll can use GetModuleFileName() to figure out from where it was loaded and attempt to parse a possible config file located in the same dir with it. If this fails it will assume that it was loaded from /bin and attempt to read the config file from ../etc. If this fails then it can throw an error or try to recover the old info from the registry and generate the file based on it. Once it knows about the system mounts it will look in the user's home dir for something like .cygwinrc and get from there any user mounts and other settings like the ones set using the CYGWIN env variable. Let me know if I missed something. Thank you, Doru Carastan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [Proposal] Moving user mount information to HKLM
On Thu, Sep 26, 2002 at 09:38:21PM -0700, Doru Carastan wrote: > How about breaking free from using the windoze registry. There is > absolutely no special need to use it IMO. I'll second that. Relying on a single monolithic binary file for system critical information is an extraordinarily bad idea. A single ill-behaved program can render the system unbootable. AFAIK, the only thing that MUST be in there is the uninstall information. -- Charles Krug, Jr. Systems Engineer Pentek Corp 1 Park Way Upper Saddle River, NJ 07458 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [Proposal] Moving user mount information to HKLM
On Thu, 26 Sep 2002, Doru Carastan wrote: > How about breaking free from using the windoze registry. There is > absolutely no special need to use it IMO. All the mount info can be stored > in a plain ASCII file like 'cygwin.cfg'. As part of its initialization the > cygwin1.dll can use GetModuleFileName() to figure out from where it was > loaded and attempt to parse a possible config file located in the same dir > with it. If this fails it will assume that it was loaded from /bin and > attempt to read the config file from ../etc. If this fails then it can > throw an error or try to recover the old info from the registry and generate > the file based on it. Once it knows about the system mounts it will look in > the user's home dir for something like .cygwinrc and get from there any user > mounts and other settings like the ones set using the CYGWIN env variable. > > Let me know if I missed something. > > Thank you, > Doru Carastan This has been suggested by Chris Faylor on the cygwin-developers list about 3 weeks ago. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Water molecules expand as they grow warmer" (C) Popular Science, Oct'02, p.51 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [Proposal] Moving user mount information to HKLM
On Fri, 2002-09-27 at 23:15, Charles Krug wrote: > On Thu, Sep 26, 2002 at 09:38:21PM -0700, Doru Carastan wrote: > > How about breaking free from using the windoze registry. There is > > absolutely no special need to use it IMO. > > I'll second that. Relying on a single monolithic binary file for system > critical information is an extraordinarily bad idea. So, you'll be glad then that windows doesn't do that :]. The design of windows itself is really something for alt.os.advocacy. Cygwin uses the registry for various settings, and will almost certainly keep using it. There is some potential work going that *may* reduce registry use, but not because of reliability problems. See the -dev archives for more info. On the user mount in HKLM idea, it's a no-goer. Normal users don't have write access to most of HKLM, on any partly-secure install of NT (which is where the original posters issue arose). Secondly, there is a much more straightforward solution for the poster: use something like mount $USERPROFILE$CYGHOME /home/$USER then /home/$user will work correctly for pwd. Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
RE: [Proposal] Moving user mount information to HKLM
> On the user mount in HKLM idea, it's a no-goer. Normal users don't > have write access to most of HKLM, on any partly-secure install > of NT (which is where the original posters issue arose). I may be wrong, but couldn't setup, or whoever creates the original HKLM/../cygwin key, set up the security attributes such that any authenticated user may write there ? > Secondly, there is a much more straightforward solution > for the poster: > use something like > mount $USERPROFILE$CYGHOME /home/$USER You mean creating permanent system mounts while running as administrator. We tried that, and hit some upper mount limit in cygwin1.dll. Try it yourself: ~>for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26; do mount h: /home/user$i; done Dan. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [Proposal] Moving user mount information to HKLM
On Sat, 2002-09-28 at 00:19, Dan Vasaru wrote: > > > On the user mount in HKLM idea, it's a no-goer. Normal users don't > > have write access to most of HKLM, on any partly-secure install > > of NT (which is where the original posters issue arose). > > I may be wrong, but couldn't setup, or whoever creates the original > HKLM/../cygwin key, set up the security attributes such that any > authenticated user may write there ? > > > Secondly, there is a much more straightforward solution > > for the poster: > > use something like > > mount $USERPROFILE$CYGHOME /home/$USER > > You mean creating permanent system mounts while running as administrator. We > tried that, and hit some upper mount limit in cygwin1.dll. Try it yourself: > > ~>for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 > 26; do mount h: /home/user$i; done Yes, it's limited to 30. See shared_info.h in the source. This affects BOTH user and system mounts. As a workaround you can hook the exiting of the login shell to unmount the path when you're finished. Hope that helps, Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
RE: [Proposal] Moving user mount information to HKLM
Robert, Your solution only works if the users are local administrators, as a domain user has no rights to HKLM (and hence to create a system mount). In our case, giving all users local administrator rights is an acceptable solution, but we're still left with a maximum of 25-30 simultaneous users. But we'll go with it while waiting for a better mount. Thanks, Dan. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Collins Sent: Friday, September 27, 2002 4:28 PM To: Dan Vasaru Cc: [EMAIL PROTECTED] Subject: RE: [Proposal] Moving user mount information to HKLM On Sat, 2002-09-28 at 00:19, Dan Vasaru wrote: > > > On the user mount in HKLM idea, it's a no-goer. Normal users don't > > have write access to most of HKLM, on any partly-secure install > > of NT (which is where the original posters issue arose). > > I may be wrong, but couldn't setup, or whoever creates the original > HKLM/../cygwin key, set up the security attributes such that any > authenticated user may write there ? > > > Secondly, there is a much more straightforward solution > > for the poster: > > use something like > > mount $USERPROFILE$CYGHOME /home/$USER > > You mean creating permanent system mounts while running as administrator. We > tried that, and hit some upper mount limit in cygwin1.dll. Try it yourself: > > ~>for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 > 26; do mount h: /home/user$i; done Yes, it's limited to 30. See shared_info.h in the source. This affects BOTH user and system mounts. As a workaround you can hook the exiting of the login shell to unmount the path when you're finished. Hope that helps, Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [Proposal] Moving user mount information to HKLM
On Sat, 2002-09-28 at 00:57, Dan Vasaru wrote: > > Robert, > > Your solution only works if the users are local administrators, as a domain > user has no rights to HKLM (and hence to create a system mount). In our > case, giving all users local administrator rights is an acceptable solution, > but we're still left with a maximum of 25-30 simultaneous users. But we'll > go with it while waiting for a better mount. > > Thanks, Dan. Excellent, I'm glad you have a workaround. FWIW the HKLM user mounts would have the same security ramification (which is why it's not a generically viable solution). Rob signature.asc Description: This is a digitally signed message part
RE: [Proposal] Moving user mount information to HKLM
Robert,
>FWIW the HKLM user mounts would have the same security
>ramification (which is why it's not a generically viable solution).
True, but one could fine-tune access rights to "HKLM/Software/Cygwin" such
that:
1) All users have "Create subkey" permission in "HKLM/./Cygwin/Users".
2) All user specific information goes under a "Cygwin/Users/{SID}" subkey.
In addition to the default rights for local admin etc, full access must be
granted to {SID}.
This would ensure that whoever is authorized to login would be able to
execute mount commands. Note that all keys down to "Users" need to be opened
for READ access only, otherwise RegOpenKey will fail with permission denied.
On another note, how about adding a flag to "mount" telling it that the
mount is NOT to be persisted, in a similar fashion to the "net use
/persistent:no" command ? This would bypass the need to write to the
registry and unmount on exit.
Thanks again,
Dan.
PS. For the archives:
Problem:
The mount -u command fails if a domain user's registry hive is not
downloaded from the domain controller and no local hive cache exists.
Current workaround:
Our best workaround is to give all potential users FullControl permissions
to the "HKLM/Software" key, and mount everything as a system mount. The
security risks are that any user can modify/change/delete all registry
information under HKLM/Software.
There's a limit of about 25 mounts that can be created this way before
hitting a built-in limit of maximum 30 mount points per system+user.
Restricting write access to the "HKLM.../cygwin/mounts v2" subkey will still
result in a "Permission denied", since cygwin 1.3.12-2 tries to open all
HKLM keys (down to "HKLM/Software/mounts v2") with write access.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [Proposal] Moving user mount information to HKLM
On 9/26/2002 9:38 PM, Doru Carastan wrote: > How about breaking free from using the windoze registry. There is > absolutely no special need to use it IMO. All the mount info can > be stored in a plain ASCII file like 'cygwin.cfg'. As part of its > initialization the cygwin1.dll can use GetModuleFileName() to figure > out from where it was loaded and attempt to parse a possible config > file located in the same dir with it. This doesn't work so good if the user doesn't have write permissions to the "bin" directory - where would the user mounts go? So then you'd need one "system mount file" (like above), and one "user mount file" per user. And where would that go? Especially if you have to do a user mount to get to the user's home directory in the first place? -- Shankar. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [Proposal] Moving user mount information to HKLM
This is totally great news. I don't monitor the deloper list but it is great to hear that my http://www.cygwin.com/ml/cygwin/2002-02/msg00805.html suggestion is being considered. I am totally sorry about the fact that I couldn't get the time to work on it. Thanks Igor, Doru Carastan - Original Message - From: "Igor Pechtchanski" <[EMAIL PROTECTED]> To: "Doru Carastan" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, September 27, 2002 6:24 AM Subject: Re: [Proposal] Moving user mount information to HKLM > On Thu, 26 Sep 2002, Doru Carastan wrote: > > > How about breaking free from using the windoze registry. There is > > absolutely no special need to use it IMO. All the mount info can be stored > > in a plain ASCII file like 'cygwin.cfg'. As part of its initialization the > > cygwin1.dll can use GetModuleFileName() to figure out from where it was > > loaded and attempt to parse a possible config file located in the same dir > > with it. If this fails it will assume that it was loaded from /bin and > > attempt to read the config file from ../etc. If this fails then it can > > throw an error or try to recover the old info from the registry and generate > > the file based on it. Once it knows about the system mounts it will look in > > the user's home dir for something like .cygwinrc and get from there any user > > mounts and other settings like the ones set using the CYGWIN env variable. > > > > Let me know if I missed something. > > > > Thank you, > > Doru Carastan > > This has been suggested by Chris Faylor on the cygwin-developers list > about 3 weeks ago. > Igor > -- > http://cs.nyu.edu/~pechtcha/ > |\ _,,,---,,_ [EMAIL PROTECTED] > ZZZzz /,`.-'`'-. ;-;;,_ [EMAIL PROTECTED] > |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski > '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! > > "Water molecules expand as they grow warmer" (C) Popular Science, Oct'02, p.51 > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [Proposal] Moving user mount information to HKLM
On Sat, Sep 28, 2002 at 06:49:00PM -0700, Doru Carastan wrote: >This is totally great news. I don't monitor the deloper list but it is great >to hear that my http://www.cygwin.com/ml/cygwin/2002-02/msg00805.html >suggestion is being considered. I am totally sorry about the fact that I >couldn't get the time to work on it. As I mentioned, in response to the above message, it's hardly a new idea. The intent is not to magically allow two different versions of the DLL to coexist. I expect that, as time progresses, there will be more checks to ensure that doesn't happen. 1.3.13 has new checks for this, in fact. You don't install two versions of linux on your system and expect them to interoperate at the same time. Ditto, cygwin. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [Proposal] Moving user mount information to HKLM
On Sat, Sep 28, 2002 at 07:47:28PM -0700, Doru Carastan wrote: >>.. I expect that, as time progresses, there will be more checks to >>ensure that doesn't happen. 1.3.13 has new checks for this, in fact. > >This makes sense only if RH views Cygwin as an Microsoft Windows OS >UNIX extension and not as a standalone UNIX emulator or VM running on >top of Windows. It makes sense in the context of many many many people having problems with two versions of cygwin in their path or even just on the system. Their problems aren't due to the fact that I'm being mean. The problems are due to the fact that cygwin makes some assumptions about the layout of areas passed between processes, both in shared memory and as part of the "cygheap". >>You don't install two versions of linux on your system and expect them >>to> interoperate at the same time. Ditto, cygwin. >It is like comparing apples with oranges. I have not seen yet Linux >running directly on top of a win32 host, nontheless cygwin running >naked without a win32 host. The point is that cygwin is essentially an "OS" in the context in which it is being used. You don't run two OS's on the system at the same time unless you're running some kind of micro-kernel or something. I am trying to set the mind set here. As the person responsible for cygwin development, that's how we are progressing. Now that you understand, by way of analogy, how we are progressing, it should be easier for you to comprehend. If you want to use a Windows analogy, think "two versions of msvcrt.dll". Having two of those in the path can also cause problems. >Everybody who read the code knows that a debug cygwin1.dll or regular >one built for a different shared memory and registry can coexist with >other versions. Actually, it doesn't work all that well, even in this context. We have a problem with this RIGHT NOW, in fact. Getting this working reliably is a constant battle. It was actually quite broken for months. It's only a little broken now. >What's wrong in having the latest 'stable' version of Cygwin and also >experimenting with the latest net release installed on the same computer. Nothing at all. Do it all the time. I switch back and forth. I actually keep two versions on my system, since I know how to do that. I just am careful not to run both at the same time or to do so in contexts that I know won't cause problems. >One can use the stable one and switch to the most recent one when percieved >as stable. Or get back to the version on which things where working fine. Sure, switch away. Copy the cygwin DLLs, using windows utilities, into your cygwin bin directory. You realize that I, and any other person who develops cygwin, has to do this all of the time, right? I'm managing quite well without having to run two versions at the same time. >It is all about freedom. Why to deliberately restrict this? Because getting it working reliably is hard and having two versions of the DLL on the system is a technical support nightmare. You obviously are not reading the cygwin mailing list. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [Proposal] Moving user mount information to HKLM
> This is in reply to Christopher Faylor's post > http://cygwin.com/ml/cygwin/2002-09/msg01430.html > > With this in mind I will like you to consider publishing in the Cygwin FAQ > the guidlines one should use for distributing an (open source) application > outside the official net release. I believe it is an important topic in the > spirit of 'getting our minds set'. > > Personally I am thinking of using the setup tool to install the packages > that creates the environment used to build the application and add the extra > application package(s) to setup.ini. I have actually thought of getting something like this together. It would include step-by-step instructions for creating your own local custom-package repository. Unfortunately this also means it would have to include discussion of upset and all the problems associated with changes in setup.exe/upset/setup.ini. Any thoughts on whether this would be worth it? __ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [Proposal] Moving user mount information to HKLM
On Mon, Sep 30, 2002 at 06:50:28AM -0700, Joshua Daniel Franklin wrote: >>This is in reply to Christopher Faylor's post >>http://cygwin.com/ml/cygwin/2002-09/msg01430.html >> >>With this in mind I will like you to consider publishing in the Cygwin >>FAQ the guidlines one should use for distributing an (open source) >>application outside the official net release. I believe it is an >>important topic in the spirit of 'getting our minds set'. >> >>Personally I am thinking of using the setup tool to install the >>packages that creates the environment used to build the application and >>add the extra application package(s) to setup.ini. > >I have actually thought of getting something like this together. It >would include step-by-step instructions for creating your own local >custom-package repository. Unfortunately this also means it would have >to include discussion of upset and all the problems associated with >changes in setup.exe/upset/setup.ini. Any thoughts on whether this >would be worth it? The goal of this mailing list and of the cygwin distribution is not to support other people in their quest to bundle and massage the standard distribution. Maybe someone should set up another mailing list or another web site to discuss this. I don't think we want to open up this topic here. We get quite enough traffic here without adding another "How do I setup.ini the upset?" questions to the mix. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
