Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Jul 24 15:40, Phil Nelson wrote: 1.5: cd /cygdrive/n ls -ldn JUNK drwxr-xr-x 1 500 513 0 May 27 10:54 JUNK 1.7: cd /cygdrive/n ls -ldn JUNK drwxr-x--- 1 4294967295 4294967295 0 Jan 14 2008 JUNK So it looks like user, group, permissions and dates are all wrong under 1.7. No, they aren't. The reason for this effect is that in 1.5, the user and group ownership, as well as the permissions were ignored by default (CYGWIN=nosmbntsec). With 1.7, CYGWIN=(no)ntsec and CYGWIN=(no)smbntsec are going away in favor of the (no)acl mount option. acl == ntsec is default. That means, you see correct permissions, but the user and group information (if not backed by a domain controller and bein available in your Cygwin's /etc/passwd and /etc/group anyway) can't be resolved unless you have matching user and group entries in /etc/passwd and /etc/group. However, there was still a problem up to 1.7.0-18 which results in a access denied message when trying to create files on a samba share with acl on. I'm just going to upload 1.7.0-21. I changed the mkpasswd and mkgroup tools so that they now allow to create passwd and group entries for users and groups from Samba servers: $ mkpasswd -L samba-machine,10 -U 0,500-510 $ mkgroup -L samba-machine,10 -U 0,users These commands will create entries from the global user list on the Samba machine (-L machinename). The local created uids will be mapped with an offset of 10. Additionally, it will create entries for the standard UNIX accounts on the Samba machine for the users with uids 0 and 500-510. Same for the groups with uid 0 and name users. The standard UNIX accounts are the ones you see in the Windows security tab as Unix User\foouser and Unix Group\foogroup. If that's all too complicated for you, use the mount option noacl for this drive. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Friday 25 July 2008 12:21:22 am Corinna Vinschen wrote: No, they aren't. The reason for this effect is that in 1.5, the user and group ownership, as well as the permissions were ignored by default (CYGWIN=nosmbntsec). Thanks. And are we starting a FAQ for things like this for 1.7? Such a change in the security model between 1.5 and 1.7 is likely to generate many questions. --Phil -- Phil Nelson (phil at cs.wwu.edu) http://www.cs.wwu.edu/nelson NetBSD: http://www.NetBSD.org Coda: http://www.coda.cs.cmu.edu signature.asc Description: This is a digitally signed message part.
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Jul 25 06:55, Phil Nelson wrote: On Friday 25 July 2008 12:21:22 am Corinna Vinschen wrote: No, they aren't. The reason for this effect is that in 1.5, the user and group ownership, as well as the permissions were ignored by default (CYGWIN=nosmbntsec). Thanks. And are we starting a FAQ for things like this for 1.7? Such a change in the security model between 1.5 and 1.7 is likely to generate many questions. Sure, and I'm three-quarter through the new documentation. FAQ didn't see any changes yet. The current unfinished state of the docs can be marveled at under http://cygwin.com/1.7/cygwin-ug-net.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Wednesday 02 April 2008 5:35:51 am Corinna Vinschen wrote: Having said that, I would like to ask especially you package maintainers to set up a separate machine or a separate cygwin directory for the 1.7 release. Well, I'm a little slow on following and I'm not an official maintainer (yet) but I am the maintainer of the Coda distribution for Windows that uses cygwin heavily. (In fact, I do have a set of sources that build cygwin packages that we currently distribute via a private mirror. I've just not done the work to do a GTG e-mail. Part of the reason is that one of the packages, the kernel module for Coda, requires a Windows build environment to be installed even though the kernel module is compiled from a UNIX makefile ... so once the extra build environments are installed, one can do make; make install in the cygwin directory tree but I digress...) I decided to try 1.7 with Coda and rather quickly got stopped by a user/group issue in 1.7. I have my primary sources copies on a NetBSD box with Samba running on it. Works great from 1.5. Map the drive in windows, use cygwin to compile via the net.In 1.7 the user and group returned is 2^32-1 () which doesn't allow me to do anything other than read on the file server. I'm not sure if this is the right list for 1.7 bugs or if they should go to another list. If I'm wrong, I'm sure someone will tell me e.g. to the same file server and ls the same 1.5: cd /cygdrive/n ls -ldn JUNK drwxr-xr-x 1 500 513 0 May 27 10:54 JUNK 1.7: cd /cygdrive/n ls -ldn JUNK drwxr-x--- 1 4294967295 4294967295 0 Jan 14 2008 JUNK So it looks like user, group, permissions and dates are all wrong under 1.7. --Phil -- Phil Nelson (phil at cs.wwu.edu) http://www.cs.wwu.edu/nelson NetBSD: http://www.NetBSD.org Coda: http://www.coda.cs.cmu.edu signature.asc Description: This is a digitally signed message part.
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, Jul 24, 2008 at 03:40:51PM -0700, Phil Nelson wrote: On Wednesday 02 April 2008 5:35:51 am Corinna Vinschen wrote: Having said that, I would like to ask especially you package maintainers to set up a separate machine or a separate cygwin directory for the 1.7 release. Well, I'm a little slow on following and I'm not an official maintainer (yet) but I am the maintainer of the Coda distribution for Windows that uses cygwin heavily. (In fact, I do have a set of sources that build cygwin packages that we currently distribute via a private mirror. I've just not done the work to do a GTG e-mail. Part of the reason is that one of the packages, the kernel module for Coda, requires a Windows build environment to be installed even though the kernel module is compiled from a UNIX makefile ... so once the extra build environments are installed, one can do make; make install in the cygwin directory tree but I digress...) I decided to try 1.7 with Coda and rather quickly got stopped by a user/group issue in 1.7. I have my primary sources copies on a NetBSD box with Samba running on it. Works great from 1.5. Map the drive in windows, use cygwin to compile via the net.In 1.7 the user and group returned is 2^32-1 () which doesn't allow me to do anything other than read on the file server. I'm not sure if this is the right list for 1.7 bugs or if they should go to another list. If I'm wrong, I'm sure someone will tell me e.g. to the same file server and ls the same 1.5: cd /cygdrive/n ls -ldn JUNK drwxr-xr-x 1 500 513 0 May 27 10:54 JUNK 1.7: cd /cygdrive/n ls -ldn JUNK drwxr-x--- 1 4294967295 4294967295 0 Jan 14 2008 JUNK So it looks like user, group, permissions and dates are all wrong under 1.7. It could look like that when you look at it from 100 yards away. To get closer we'd need to see things like what your /etc/passwd and /etc/group files look like. Even cygcheck output would help. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 22 18:00, Corinna Vinschen wrote: On Apr 22 11:51, Charles Wilson wrote: Brian Dessent wrote: the DLL already supports parallel installs by the fact that it uses /etc/fstab. Only in very limited cases: [...] Right? You still have to worry about the shared memory region name, and its format which may vary with DLL version. Plus there still might be other stuff that prevents parallel cygwin installs from running simultaneously. And I don't think supporting simultaneous use of multiple cygwin installations is one of our goals, is it? In theory, the latest incarnation of the Cygwin DLL should work in parallel with a 1.5.x DLL. In theory. I didn't actually test it. Now I did. I installed the 1.7 release first, a few days ago, into C:\cygwin. My first step installing 1.5 was to rename C:\cygwin to C:\somethingelse. Then I removed the registry keys HKCU\Software\Cygnus Solutions and HKLM\SOFTWARE\Cygnus Solutions and installed 1.5 into a directory called C:\cygwin-1.5. Finally I renamed C:\somethingelse back to C:\cygwin. I'm just running a 1.5 and a 1.7 shell concurrently and both are alive and healthy. None of them know from each other, they have separate process lists, separate /proc dirs, separate everything. Just this note: Don't mix processes started from the 1.5 and 1.7 installations within the same shell. Keep 1.5 and 1.7 process trees separate. You have been warned. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
P?teris K?avi? wrote: So why can't the registry entry be path-to-dll instead of the fixed 'setup\rootdir' in order that the setup application could populate a drop-down list of all currently installed Cygwins? It could. But I think Chuck made a good point that the ability to have multiple installed copies extends to what you might call expert users, i.e. they must know the ins and outs of not actually ever using these two installs at once. And so we need to be careful not to give the impression that this is supposed to work in the general case. Maybe all cyg*.exe native Windows applications could use this same algorithm to compute their root. cygcheck and strace are the only things that use the code in question, and strace only uses it for the purpose of resolving the win32 filename of the output file specified with -o. Would this problem go away if cygrunsrv.exe used the same algorithm to compute its root? No, the problem is that the operating system's service configuration in the registry needs the path to cygrunsrv.exe -- it needs to know the path to the image to execute, and we of course have no control over that. The only workaround I can think of to providing an absolute path would be to use the REG_EXPAND_SZ key type's capability to expand variables from the environment, e.g. %CygwinRoot%\bin\cygrunsrv.exe. However, this doesn't really solve anything, it just shifts the problem to making sure this variable is set. And even if you figured out a way to do that, the change in environment would not take effect in the services.exe process until the next time it was started, i.e. a reboot. It would still be easier just to edit the service config after moving the files. I have (finally) started using an environment where I share all my personal files on a separate disk drive accessible from all my bootable operating systems, whether it's Vista, WS2008, or Debian. The drive names (and mount points) vary. It's the same as moving install trees, and it would be nice if Cygwin didn't really care that when I started the services this time they were started from a different location than last time. In this case the problem has nothing to do with any code in Cygwin. But no I don't see your situation as the same, since as long as the location is consistent on any given system, you can install the service once and it will continue to be correct from there on. Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Brian Dessent wrote: So why can't the registry entry be path-to-dll instead of the fixed 'setup\rootdir' in order that the setup application could populate a drop-down list of all currently installed Cygwins? It could. Excellent. I second your suggestion. :-) But I think Chuck made a good point that the ability to have multiple installed copies extends to what you might call expert users, i.e. they must know the ins and outs of not actually ever using these two installs at once. And so we need to be careful not to give the impression that this is supposed to work in the general case. Sigh. Yes I read Chuck's clear denouncement that there is any whisper of there being a goal to support multiple Cygwin DLL's running simultaneously. However, that doesn't stop me from lobbying for setting up such a goal, and having a path-to-dll registry entry for the Cygwin DLL would be a step towards it, even if in the short term there was only one such path allowed in the registry, i.e., subsequent Cygwin setups would remove the previous path and replace it with the current user's choice, if it was different. Peter Klavins
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen wrote:
it just occured to me that I need the exact key name which setup will
use to store the root directory of the installation. I nedd it to get
cygcheck working, even if it's not installed into the same path as the
Cygwin DLL.
{HKLM,HKCU}\Software\Cygwin\???
??? = Setup\root maybe? Or with a version number?
A good question. I haven't implemented anything yet, so we can choose
whatever we want. I wonder if it's really necessary to have a whole
subkey for this since at the moment there is only the one value that
setup will read. How about simply \Software\Cygwin\rootdir?
That reminds me of something... I've always been a bit annoyed that
people always resort to manually editing the registry to remove Cygwin,
when umount is the documented and preferred method. But now, we will
have no such utility to suggest and so to remove Cygwin the user will be
forced to use regedit. Combined with the fact that most users trip over
the fact that sometimes ACLs on files like /var/log/sshd.log require
them to take ownership before deleting, I would like to be able to offer
an uninstaller. This would handle checking for running Cygwin processes
and prompting to exit them (or terminating them), stopping and
uninstalling all Cygwin services, deleting the entire Cygwin tree,
removing start menu and desktop icons, removing everything from the
registry, and whatever else is necessary. It would be the nuclear
option, deleting without remorse all traces with one click; I think
users want this. It would of course be a standalone MinGW app like
setup.exe, except that it would get installed somewhere in the tree, and
added to the add/remove applet. Anyway, SHTDI and everything but I just
want to float the idea to gauge response.
Brian
RE: [HEADSUP] Let's start a Cygwin 1.7 release area
[EMAIL PROTECTED] wrote:
Corinna Vinschen wrote:
it just occured to me that I need the exact key name which setup will
use to store the root directory of the installation. I nedd it to
get cygcheck working, even if it's not installed into the same path
as the Cygwin DLL.
{HKLM,HKCU}\Software\Cygwin\???
??? = Setup\root maybe? Or with a version number?
A good question. I haven't implemented anything yet, so we can choose
whatever we want. I wonder if it's really necessary to have a whole
subkey for this since at the moment there is only the one value that
setup will read. How about simply \Software\Cygwin\rootdir?
That reminds me of something... I've always been a bit annoyed that
people always resort to manually editing the registry to
remove Cygwin,
when umount is the documented and preferred method. But now, we will
have no such utility to suggest and so to remove Cygwin the
user will be
forced to use regedit.
regtool remove {HKLM,HKCU}\Software\Cygwin\???
Combined with the fact that most
users trip over
the fact that sometimes ACLs on files like /var/log/sshd.log require
them to take ownership before deleting, I would like to be
able to offer
an uninstaller. This would handle checking for running
Cygwin processes
and prompting to exit them (or terminating them), stopping and
uninstalling all Cygwin services, deleting the entire Cygwin tree,
removing start menu and desktop icons, removing everything from the
registry, and whatever else is necessary. It would be the nuclear
option, deleting without remorse all traces with one click; I think
users want this. It would of course be a standalone MinGW app like
setup.exe, except that it would get installed somewhere in
the tree, and
added to the add/remove applet. Anyway, SHTDI and everything
but I just
want to float the idea to gauge response.
Guess, it's nevertheless a good idea ...
- Jörg
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Jörg Schaible wrote:
That reminds me of something... I've always been a bit annoyed that
people always resort to manually editing the registry to
remove Cygwin,
when umount is the documented and preferred method. But now, we will
have no such utility to suggest and so to remove Cygwin the
user will be
forced to use regedit.
regtool remove {HKLM,HKCU}\Software\Cygwin\???
I suppose I didn't state my point very well. Yes, there are Cygwin
tools for manipulating the registry. But the registry is an
implementation detail, and you should not need to know anything about
registry keys to uninstall Cygwin. At the moment this can be
accomplished via umount -A (and cygrunsrv -R) with zero knowledge of
where the mount table happens to be implemented, or that there even is a
registry.
With the mount table no longer stored in the registry, we will have no
way around saying you must remove such-and-such key from the
registry. This is bad, IMHO.
A separate issue is that even if we document a proper procedure for
removing Cygwin (as we currently do in the FAQ), users often don't read
manuals and just plunge in and try to delete stuff. They fail because
they forgot to stop services first, or because they don't understand
file ACLs. By adding a new key in the registry we make it increasingly
likely that in their fervor to dive in and delete things without reading
docs they will miss yet another step. I want to finally solve this for
good by making a program that encapsulates all this knowledge so that
they don't have to RTFM, and so that they just have a nice thing to
click on like every other well-behaved Windows program. I think it's
been a requested feature more than once.
Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 21 23:02, Brian Dessent wrote:
Corinna Vinschen wrote:
it just occured to me that I need the exact key name which setup will
use to store the root directory of the installation. I nedd it to get
cygcheck working, even if it's not installed into the same path as the
Cygwin DLL.
{HKLM,HKCU}\Software\Cygwin\???
??? = Setup\root maybe? Or with a version number?
A good question. I haven't implemented anything yet, so we can choose
whatever we want. I wonder if it's really necessary to have a whole
subkey for this since at the moment there is only the one value that
setup will read. How about simply \Software\Cygwin\rootdir?
I would suggest to use a setup subkey, because you might find that
you have to store more than one value at one point. It would be
cleaner this way, imho. And originally we came up with the version
number, too, so what about setup-2 or setup?
Anyway, it's your decision. I will go with whatever you think is
approriate. I just need to know so I can fix utils/path.cc.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen wrote: I would suggest to use a setup subkey, because you might find that you have to store more than one value at one point. It would be cleaner this way, imho. And originally we came up with the version number, too, so what about setup-2 or setup? Traditionally setup has stored all of its state in files under /etc/setup. I think this is a good thing to continue, since it makes it easy to access and manipulate them from scripts. Given that we're moving the mount table out of the registry and into /etc, I don't see why we'd want to do the reverse with setup's bits. So in that sense, I don't see a need for a subkey that will only ever have one key. On the other hand, I'd hate for a bad decision now to make things annoying in the future. Let me ask this: what's the layout for the other items that will still be in the registry? Are we still looking at: \Software\Cygwin\Program Options\default \Software\Cygwin\Program Options\foo.exe \Software\Cygwin\Program Options\bar.exe \Software\Cygwin\heap_chunk_in_mb \Software\Cygwin\heap_slop_in_mb This is kind of ugly too, we have a mix of things with spaces and underscores. How about the following: \Software\Cygwin\setup\rootdir \Software\Cygwin\options\heap_chunk_in_mb \Software\Cygwin\options\heap_slop_in_mb \Software\Cygwin\options\defaults \Software\Cygwin\options\app-specific\foo.exe \Software\Cygwin\options\app-specific\bar.exe Or, perhaps: \Software\Cygwin\rootdir \Software\Cygwin\heap_chunk_in_mb \Software\Cygwin\heap_slop_in_mb \Software\Cygwin\default_options \Software\Cygwin\app-specific\foo.exe \Software\Cygwin\app-specific\bar.exe I really don't know. (The version number I think is implicit in the fact that this is a totally new key that's never been used before. If in the very distant future setup needs yet another namespace it can have a setup-2 subkey then.) Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 22 02:46, Brian Dessent wrote: Corinna Vinschen wrote: I would suggest to use a setup subkey, because you might find that you have to store more than one value at one point. It would be cleaner this way, imho. And originally we came up with the version number, too, so what about setup-2 or setup? Traditionally setup has stored all of its state in files under /etc/setup. I think this is a good thing to continue, since it makes it easy to access and manipulate them from scripts. Given that we're moving the mount table out of the registry and into /etc, I don't see why we'd want to do the reverse with setup's bits. So in that sense, I don't see a need for a subkey that will only ever have one key. On the other hand, I'd hate for a bad decision now to make things annoying in the future. Let me ask this: what's the layout for the other items that will still be in the registry? Are we still looking at: \Software\Cygwin\Program Options\default \Software\Cygwin\Program Options\foo.exe \Software\Cygwin\Program Options\bar.exe \Software\Cygwin\heap_chunk_in_mb \Software\Cygwin\heap_slop_in_mb This is kind of ugly too, we have a mix of things with spaces and underscores. How about the following: \Software\Cygwin\setup\rootdir \Software\Cygwin\options\heap_chunk_in_mb \Software\Cygwin\options\heap_slop_in_mb \Software\Cygwin\options\defaults \Software\Cygwin\options\app-specific\foo.exe \Software\Cygwin\options\app-specific\bar.exe Or, perhaps: \Software\Cygwin\rootdir \Software\Cygwin\heap_chunk_in_mb \Software\Cygwin\heap_slop_in_mb \Software\Cygwin\default_options \Software\Cygwin\app-specific\foo.exe \Software\Cygwin\app-specific\bar.exe I really don't know. I don't know either. I'm not going to change what's in Cygwin right now since it's seldomly used anyway. So, for now, let's just agree on \Software\Cygwin\setup\rootdir so I can patch utils/path.cc and upload a new cygwin 1.7.0-4, ok? (The version number I think is implicit in the fact that this is a totally new key that's never been used before. If in the very distant future setup needs yet another namespace it can have a setup-2 subkey then.) Fine with me. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen wrote: I don't know either. I'm not going to change what's in Cygwin right now since it's seldomly used anyway. So, for now, let's just agree on \Software\Cygwin\setup\rootdir so I can patch utils/path.cc and upload a new cygwin 1.7.0-4, ok? Okay, let's go with that. Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 22 01:25, Brian Dessent wrote: I suppose I didn't state my point very well. Yes, there are Cygwin tools for manipulating the registry. But the registry is an implementation detail, and you should not need to know anything about registry keys to uninstall Cygwin. At the moment this can be accomplished via umount -A (and cygrunsrv -R) with zero knowledge of where the mount table happens to be implemented, or that there even is a registry. With the mount table no longer stored in the registry, we will have no way around saying you must remove such-and-such key from the registry. This is bad, IMHO. A separate issue is that even if we document a proper procedure for removing Cygwin (as we currently do in the FAQ), users often don't read manuals and just plunge in and try to delete stuff. They fail because they forgot to stop services first, or because they don't understand file ACLs. By adding a new key in the registry we make it increasingly likely that in their fervor to dive in and delete things without reading docs they will miss yet another step. I want to finally solve this for good by making a program that encapsulates all this knowledge so that they don't have to RTFM, and so that they just have a nice thing to click on like every other well-behaved Windows program. I think it's been a requested feature more than once. Btw., I think that an uninstall option would be a good thing. While I talked about the cyglsa DLL in my reply to Chuck on the Cygwin ML, it occured to me that this would be a job for the uninstaller as well: If the cyglsa DLL has been added to the registry value HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages it's not possible to remove the DLL unless you reboot. So, what the uninstaller would have to do is to remove the substring which contains cyglsa.dll or cyglsa64.dll from the above registry value and then to add the DLL to the PendingFileRenameOperations registry value. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Brian Dessent wrote: Corinna Vinschen wrote: I don't know either. I'm not going to change what's in Cygwin right now since it's seldomly used anyway. So, for now, let's just agree on \Software\Cygwin\setup\rootdir so I can patch utils/path.cc and upload a new cygwin 1.7.0-4, ok? Does the Cygwin DLL know its own path? If so, how about \Software\Cygwin\path-to-dll ... to allow multiple parallel Cygwin installs? Peter Klavins
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
P?teris K?avi? wrote: Does the Cygwin DLL know its own path? If so, how about \Software\Cygwin\path-to-dll ... to allow multiple parallel Cygwin installs? I think you've missed the context of this discussion. This key will never be read or written by the DLL, and the DLL already supports parallel installs by the fact that it uses /etc/fstab. Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Brian Dessent wrote: P?teris K?avi?š wrote: Does the Cygwin DLL know its own path? If so, how about \Software\Cygwin\path-to-dll ... to allow multiple parallel Cygwin installs? I think you've missed the context of this discussion. This key will never be read or written by the DLL, and the DLL already supports parallel installs by the fact that it uses /etc/fstab. Hmm. Well, if it's only setup that needs the registry entry, and if multiple setups, regardless of path-to-setup, are using the same fixed registry entry serially, what's the point of the registry entry? Remembering where the last setup's root was? Which could have been moved by the user afterwards? Peter Klavins
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 22 04:07, Brian Dessent wrote: Corinna Vinschen wrote: I don't know either. I'm not going to change what's in Cygwin right now since it's seldomly used anyway. So, for now, let's just agree on \Software\Cygwin\setup\rootdir so I can patch utils/path.cc and upload a new cygwin 1.7.0-4, ok? Okay, let's go with that. I've checked in the patch and uploaded a new 1.7.0-4 package to the release-2 area. Maybe trhat helps for testing setup, too. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
P?teris K?avi? wrote: Hmm. Well, if it's only setup that needs the registry entry, and if multiple setups, regardless of path-to-setup, are using the same fixed registry entry serially, what's the point of the registry entry? So that when you run setup it can start out with the same root that you last used so that you don't have to type it in every time. Remembering where the last setup's root was? That, and also so that the native tools like cygcheck can locate the root dir. This will be a minor problem in that if you had two installs, both cygchecks will think the root is the last one that you updated with setup. Corinna, perhaps cygcheck needs to compute the root relative to its location like the DLL instead. This means cygcheck will always have to be in /bin, but I think that's fine; it's not like it has ever been anywhere else. Which could have been moved by the user afterwards? Manually moving an installed cygwin tree would be a silly thing to do, it would break all your services for example. Anyway, if someone were silly enough to do that they would just need to enter the new location in setup; but this will be the case whether or not setup remembers its last install root, so I don't see how this is pertinent. Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Brian Dessent wrote: the DLL already supports parallel installs by the fact that it uses /etc/fstab. Only in very limited cases: (1) we're talking about cygwin-1.7.x (2) Either (a) only one of those parallel instances is in use at a time, including installed services, or (b) all of those parallel instances have exactly the same version of the DLL (3) Even so, doing this is not officially supported (the current dual-installation support vis-a-vis cygwin-1.5.x and cygwin-1.7.x is (a) temporary and (b) intended for package maintainers only, in order to prepare the cygwin-1.7 packages -- and package maintainers generally know what they are doing and what the pitfalls of a dual/multiple installation are. Right? You still have to worry about the shared memory region name, and its format which may vary with DLL version. Plus there still might be other stuff that prevents parallel cygwin installs from running simultaneously. And I don't think supporting simultaneous use of multiple cygwin installations is one of our goals, is it? -- Chuck
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 22 11:51, Charles Wilson wrote: Brian Dessent wrote: the DLL already supports parallel installs by the fact that it uses /etc/fstab. Only in very limited cases: (1) we're talking about cygwin-1.7.x (2) Either (a) only one of those parallel instances is in use at a time, including installed services, or (b) all of those parallel instances have exactly the same version of the DLL (3) Even so, doing this is not officially supported (the current dual-installation support vis-a-vis cygwin-1.5.x and cygwin-1.7.x is (a) temporary and (b) intended for package maintainers only, in order to prepare the cygwin-1.7 packages -- and package maintainers generally know what they are doing and what the pitfalls of a dual/multiple installation are. Right? You still have to worry about the shared memory region name, and its format which may vary with DLL version. Plus there still might be other stuff that prevents parallel cygwin installs from running simultaneously. And I don't think supporting simultaneous use of multiple cygwin installations is one of our goals, is it? In theory, the latest incarnation of the Cygwin DLL should work in parallel with a 1.5.x DLL. In theory. I didn't actually test it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Charles Wilson wrote: (1) we're talking about cygwin-1.7.x (2) Either (a) only one of those parallel instances is in use at a time, including installed services, or (b) all of those parallel instances have exactly the same version of the DLL Right, I don't think anyone is talking about having two trees in use simultaneously. (3) Even so, doing this is not officially supported (the current dual-installation support vis-a-vis cygwin-1.5.x and cygwin-1.7.x is (a) temporary and (b) intended for package maintainers only, in order to prepare the cygwin-1.7 packages -- and package maintainers generally know what they are doing and what the pitfalls of a dual/multiple installation are. At the moment this is quite experimental, yes; but I don't see any reason why it would be a temporary arrangement. Once we get the changes in setup.exe and 1.7 released, it will still be possible to keep multiple parallel installs by just changing the root dir in setup to select which one to install/update. Why would we want to prevent that from working? Isn't this one of the desired payoffs of moving the mount table out of the registry in the first place? Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Tue, 22 Apr 2008 09:07:34 -0700, Brian Dessent said: Charles Wilson wrote: (1) we're talking about cygwin-1.7.x (2) Either (a) only one of those parallel instances is in use at a time, including installed services, or (b) all of those parallel instances have exactly the same version of the DLL Right, I don't think anyone is talking about having two trees in use simultaneously. I just didn't want somebody searching the archives to think cygwin-1.7 officially supported lots of different cygwin1.dlls scattered all over the filesystem, all in use at the same time. It doesn't. (3) Even so, doing this is not officially supported (the current dual-installation support vis-a-vis cygwin-1.5.x and cygwin-1.7.x is (a) temporary and (b) intended for package maintainers only, in order to prepare the cygwin-1.7 packages -- and package maintainers generally know what they are doing and what the pitfalls of a dual/multiple installation are. At the moment this is quite experimental, yes; but I don't see any reason why it would be a temporary arrangement. Once we get the changes in setup.exe and 1.7 released, it will still be possible to keep multiple parallel installs by just changing the root dir in setup to select which one to install/update. Why would we want to prevent that from working? Isn't this one of the desired payoffs of moving the mount table out of the registry in the first place? I didn't say we would *break* it. There's a difference between it happens to work and is a supported configuration. During the buildup to 1.7.0-release, it's going to be a de-facto supported configuration -- if there are problems, they'll need to be fixed so that maintainers can build 1.7 packages. (Although Corinna recommended using completely separate (possibly virtual) machines for 1.5 and 1.7). After that, it's probably caveat emptor. Right now, we can tell a user to run 'cygcheck -s -v -r' and point to multiple cygwin dll's and tell 'em to fix that first, PERIOD, unless they really know what they are doing. After the official 1.7.0 rollout, unless we really truly actually support simultaneous *use* of multiple cygwin trees -- which we do not and will not -- I don't want to support/debug/handhold multiple simultaneous *installations* of cygwin, either. Because it's way too easy to slide from simultaneous installation to simultaneous use unless you are very careful. During the transition, we *will* run into that problem -- but maintainers can be trusted to usually figure those problems out on their own. -- Chuck
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Brian Dessent wrote: P?teris K?avi?š wrote: So that when you run setup it can start out with the same root that you last used so that you don't have to type it in every time. That, and also so that the native tools like cygcheck can locate the root dir. So why can't the registry entry be path-to-dll instead of the fixed 'setup\rootdir' in order that the setup application could populate a drop-down list of all currently installed Cygwins? This will be a minor problem in that if you had two installs, both cygchecks will think the root is the last one that you updated with setup. Corinna, perhaps cygcheck needs to compute the root relative to its location like the DLL instead. This means cygcheck will always have to be in /bin, but I think that's fine; it's not like it has ever been anywhere else. Maybe all cyg*.exe native Windows applications could use this same algorithm to compute their root. Manually moving an installed cygwin tree would be a silly thing to do, it would break all your services for example. Would this problem go away if cygrunsrv.exe used the same algorithm to compute its root? Anyway, if someone were silly enough to do that they would just need to enter the new location in setup; but this will be the case whether or not setup remembers its last install root, so I don't see how this is pertinent. I have (finally) started using an environment where I share all my personal files on a separate disk drive accessible from all my bootable operating systems, whether it's Vista, WS2008, or Debian. The drive names (and mount points) vary. It's the same as moving install trees, and it would be nice if Cygwin didn't really care that when I started the services this time they were started from a different location than last time. [In any case, Brian, I appreciate your time in answering my off-beat questions and realise that they aren't 'core' to the business of getting Cygwin to work. Sooner or later I'll put together the correct build environment, something which has eluded me as yet, to produce some diff's of ideas I have, rather than just talk about them.] Peter Klavins
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 20 11:45, Christopher Faylor wrote: Since most of what I did was automated, I probably ended up deleting too much. Please take a look at the package directories that you maintain and verify that the release-2 directory contains something that makes sense. My packages seem to be fine. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 16 10:44, Corinna Vinschen wrote:
On Apr 15 19:28, Brian Dessent wrote:
So, with that in
mind, are there any objections to simply HK{LM,CU}\Software\Cygwin?
Just go ahead.
I did now. I just checked in a change which
- drops reading mount points from the registry entirely,
- let the postinstall script (which still should be moved to its own
package) create /etc/fstab entries from the old system registry
mount points.
- Sets the Cygwin parent registry keys to HKLM\Software\Cygwin and
HKCU\Software\Cygwin.
I guess now the way is free for setup.exe to utilize the new registry
locations as well.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 21 16:04, Corinna Vinschen wrote:
On Apr 16 10:44, Corinna Vinschen wrote:
On Apr 15 19:28, Brian Dessent wrote:
So, with that in
mind, are there any objections to simply HK{LM,CU}\Software\Cygwin?
Just go ahead.
I did now. I just checked in a change which
- drops reading mount points from the registry entirely,
- let the postinstall script (which still should be moved to its own
package) create /etc/fstab entries from the old system registry
mount points.
- Sets the Cygwin parent registry keys to HKLM\Software\Cygwin and
HKCU\Software\Cygwin.
I guess now the way is free for setup.exe to utilize the new registry
locations as well.
Btw., just FYI, utils/path.cc doesn't build right now since it still
tries to pull mount points from the registry. I'm working on changing
that to utilizing fstab files instead.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Brian,
On Apr 21 19:48, Corinna Vinschen wrote:
On Apr 21 16:04, Corinna Vinschen wrote:
On Apr 16 10:44, Corinna Vinschen wrote:
On Apr 15 19:28, Brian Dessent wrote:
So, with that in
mind, are there any objections to simply HK{LM,CU}\Software\Cygwin?
Just go ahead.
I did now. I just checked in a change which
- drops reading mount points from the registry entirely,
- let the postinstall script (which still should be moved to its own
package) create /etc/fstab entries from the old system registry
mount points.
- Sets the Cygwin parent registry keys to HKLM\Software\Cygwin and
HKCU\Software\Cygwin.
I guess now the way is free for setup.exe to utilize the new registry
locations as well.
Btw., just FYI, utils/path.cc doesn't build right now since it still
tries to pull mount points from the registry. I'm working on changing
that to utilizing fstab files instead.
it just occured to me that I need the exact key name which setup will
use to store the root directory of the installation. I nedd it to get
cygcheck working, even if it's not installed into the same path as the
Cygwin DLL.
{HKLM,HKCU}\Software\Cygwin\???
??? = Setup\root maybe? Or with a version number?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 21 10:33, Corinna Vinschen wrote: On Apr 20 11:45, Christopher Faylor wrote: Since most of what I did was automated, I probably ended up deleting too much. Please take a look at the package directories that you maintain and verify that the release-2 directory contains something that makes sense. My packages seem to be fine. However, there was something wrong with the cygwin package directory. An ls shows a 1.5.19-4 binary package with no sources and a binary and source package version 1.7-1, which never existed before. Also, even though the directory permissions are 2775, and even though I'm in group cygwin as the directorie's group, I can't add or remove files. I had to do that as root. For some reason, I had to delete the cygwin-1.5.19-4.tar.bz2 file twice. I got no error message the first time, but owner and group were changed from root.root to cyguser.cygwin. The second rm actually deleted the file. Are you sure we can trust this unionfs implementation? It seems a bit unfinshed. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Mon, Apr 21, 2008 at 10:34:12PM +0200, Corinna Vinschen wrote: On Apr 21 10:33, Corinna Vinschen wrote: On Apr 20 11:45, Christopher Faylor wrote: Since most of what I did was automated, I probably ended up deleting too much. Please take a look at the package directories that you maintain and verify that the release-2 directory contains something that makes sense. My packages seem to be fine. However, there was something wrong with the cygwin package directory. An ls shows a 1.5.19-4 binary package with no sources and a binary and source package version 1.7-1, which never existed before. Both were just my playing with the cygwin directory. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Wed, Apr 16, 2008 at 12:24:46PM -0400, Christopher Faylor wrote: On Wed, Apr 16, 2008 at 11:39:16AM +0200, Corinna Vinschen wrote: On Apr 15 20:51, Lapo Luchini wrote: PS: my only WinXP box is still waiting for his motherboard back from RMA... I'll try qemu to test cygwin-1.7 and, if it's not too slow, produce updated packages for both 1.5 and 1.7 (or is 1.7 near enough that is better to update that first?). We will not make 1.7 an official release for some time. For the official release, please stick to 1.5. You can create update packages for 1.7 for your local installation, but let's wait a couple of days uploading 1.7 packages until Chris changed the release area to use unionfs. I played around a little more with this and found some problems that I have to investigate. When I move a file into the area from another directory it gives an error. That isn't really a big deal but I don't like putting things into production with known problems unless I have a vague understanding of the problem. So it will be a couple more days before I have the time to track this down. The size of this new, purged area is: 1926596K bytes. (I fixed my purge script) The new directory has been set up. release-2 is a union file system with the standard cygwin release as a read-only component of the directory. I removed the _obsolete directory, and should have removed everything which was in the obsolete Category. I've indiscriminately purged any package which sorted lexically less (using the upset version sort algorithm) than what seemed to be the most recent package. Since most of what I did was automated, I probably ended up deleting too much. Please take a look at the package directories that you maintain and verify that the release-2 directory contains something that makes sense. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Christopher Faylor wrote: Since most of what I did was automated, I probably ended up deleting too much. Please take a look at the package directories that you maintain and verify that the release-2 directory contains something that makes sense. If we find a problem, how should we fix it? For instance, release(1) inetutils has prev: 1.3.2-37, curr: 1.3.2-40, and test: 1.5-3. release-2 has only 1.5-3, but its setup still specified that 1.5-3 is test (it also specifies the non-existant 1.3.2-40 and 1.3.2-37 packages as curr: and prev:, respectively). I'm not ready to make inetutils-1.5-3 curr: on the release(1) side. However, since ALL of release-2 is test:, I could see doing any of the following: (1) copy over the 1.3.2-40 packages, and remove the prev: entry from setup.hint (2) change the release-2 setup.hint so that on that side, inetutils-1.5-3 becomes curr: (and remove all references in setup.hint to the missing packages). (3) change the release-2 setup.hint by removing all references to the missing packages, but otherwise leave things along. That is, on the release-2 side, inetutils would ONLY be available as a test release, until I manually promote 1.5-3. But I'm not really sure how union fs works. Can I edit setup.hint in place? Can I copy back the missing files, or is there some special procedure that makes them re-appear? -- Chuck
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Sun, Apr 20, 2008 at 02:46:28PM -0400, Charles Wilson wrote: Christopher Faylor wrote: Since most of what I did was automated, I probably ended up deleting too much. Please take a look at the package directories that you maintain and verify that the release-2 directory contains something that makes sense. If we find a problem, how should we fix it? For instance, release(1) inetutils has prev: 1.3.2-37, curr: 1.3.2-40, and test: 1.5-3. release-2 has only 1.5-3, but its setup still specified that 1.5-3 is test (it also specifies the non-existant 1.3.2-40 and 1.3.2-37 packages as curr: and prev:, respectively). I'm not ready to make inetutils-1.5-3 curr: on the release(1) side. However, since ALL of release-2 is test:, I could see doing any of the following: (1) copy over the 1.3.2-40 packages, and remove the prev: entry from setup.hint (2) change the release-2 setup.hint so that on that side, inetutils-1.5-3 becomes curr: (and remove all references in setup.hint to the missing packages). (3) change the release-2 setup.hint by removing all references to the missing packages, but otherwise leave things along. That is, on the release-2 side, inetutils would ONLY be available as a test release, until I manually promote 1.5-3. But I'm not really sure how union fs works. Can I edit setup.hint in place? Can I copy back the missing files, or is there some special procedure that makes them re-appear? I think the simplest thing to do is remove the test from setup.hint. It's all test anyway. Anyone who is using this should be extremely aware of the fact that it's unstable. Apparently there is a bug in this version of unionfs, though. If you try to recreate a missing file by just copying it in or touching it you get a File exists error and that's not right. You aren't supposed to have to know that there is something special going on and a mysterious error like that sort of breaks that assumption. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Sun, Apr 20, 2008 at 05:56:17PM -0400, Christopher Faylor wrote: Apparently there is a bug in this version of unionfs, though. If you try to recreate a missing file by just copying it in or touching it you get a File exists error and that's not right. You aren't supposed to have to know that there is something special going on and a mysterious error like that sort of breaks that assumption. Please hold off making any changes to anything in the release-2 area. I want to try another unionfs implementation which doesn't seem to have this problem. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Christopher Faylor wrote: I think the simplest thing to do is remove the test from setup.hint. It's all test anyway. Anyone who is using this should be extremely aware of the fact that it's unstable. OK. Changes I made in the release-2 area: 1) inetutils: made test release 1.5-3 current 2) libtool: made test release 2.2.2-2 current; removed versioned requires (made global). Removed libltdl3 from requires. 3) libltdl3: copied over old libtool-1.5.27a-1-src package as libltdl3-1.5.27a-1-src, and removed external-source: line from libltdl3's setup.hint. 4) login: made test release 1.9-8 current 5) pkg-config: made test release 0.23a-1 current 6) rxvt: removed reference to non-existent prev: version 7) tcp_wrappers: removed reference to non-existent prev: version, and versioned requires (made global). 7a) libwrap0: removed versioned requires (made global). 7b) libwrap-devel: removed versioned requires (made global). I did not remove the xpm-nox package, but maybe we should. It has been superseded by the libXpm-noX package for years. The old package provides cygXpm-noX4.dll while the new package (built using libtool) provides cygXpm-noX-4.dll There are no packages in either the release or release-2 areas that rely on the old package. This is odd, tho: $ pwd .../pub/cygwin/release $ find . -name setup.hint | grep libXpm-noX ./libXpm-noX/setup.hint ./libXpm-noX/libXpm-noX-devel/setup.hint ./libXpm-noX/libXpm-noX_4/setup.hint $ cd ../release-2 $ pwd .../pub/cygwin/release-2 $ find . -name setup.hint | grep libXpm-noX $ ls libXpm-noX/setup.hint libXpm-noX/setup.hint $ ls libXpm-noX/libXpm-noX-devel/setup.hint libXpm-noX/libXpm-noX-devel/setup.hint $ ls libXpm-noX/libXpm-noX_4/setup.hint libXpm-noX/libXpm-noX_4/setup.hint Huh? Here's a list of setup.hint files in the release-2 area that have test:, priv:, or curr: specifiers -- but given the weirdness above, I'm not sure it is comprehensive. $ find . -name setup.hint |\ xargs grep -l -E 'test:|curr:|prev:' |\ sort | uniq | sed -e 's/^\.\///' emacs/emacs-el/setup.hint emacs/emacs-X11/setup.hint emacs/setup.hint gdb/setup.hint grace/setup.hint postgresql/libecpg-compat2/setup.hint postgresql/libpq3/setup.hint postgresql/setup.hint xemacs/setup.hint xemacs/xemacs-emacs-common/setup.hint xemacs/xemacs-tags/setup.hint Apparently there is a bug in this version of unionfs, though. If you try to recreate a missing file by just copying it in or touching it you get a File exists error and that's not right. You aren't supposed to have to know that there is something special going on and a mysterious error like that sort of breaks that assumption. So how does this work in the future? If I have upload a new package to the (old) release area, it will also appear in the release-2 area? If I edit the setup.hint in the (old) release area, those changes will show up in the release-2 area, UNLESS I or someone else has already modified the release-2 setup.hint? (and don't delete anything from the release-2 area unless you're really really sure you'll never want to put it back g) -- Chuck
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Christopher Faylor wrote: Please hold off making any changes to anything in the release-2 area. I want to try another unionfs implementation which doesn't seem to have this problem. Whoops. Don't worry, you can blow away my changes. I've got a handy email that lists all the changes I made. g -- Chuck
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Sun, Apr 20, 2008 at 06:43:35PM -0400, Charles Wilson wrote: Christopher Faylor wrote: Please hold off making any changes to anything in the release-2 area. I want to try another unionfs implementation which doesn't seem to have this problem. Whoops. Don't worry, you can blow away my changes. I've got a handy email that lists all the changes I made. g I think I recreated the area complete with your changes. Let me know if I screwed anything up. This making changes to an area which is actively being rsynced and potentially being worked on is nerve-wracking. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Christopher Faylor wrote: I think I recreated the area complete with your changes. Let me know if I screwed anything up. Nope, all my changes are still there. The weird behavior with 'find' is still there, too. :-( This making changes to an area which is actively being rsynced and potentially being worked on is nerve-wracking. g -- Chuck
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 15 19:28, Brian Dessent wrote:
So, with that in
mind, are there any objections to simply HK{LM,CU}\Software\Cygwin?
Just go ahead.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 15 20:51, Lapo Luchini wrote: PS: my only WinXP box is still waiting for his motherboard back from RMA... I'll try qemu to test cygwin-1.7 and, if it's not too slow, produce updated packages for both 1.5 and 1.7 (or is 1.7 near enough that is better to update that first?). We will not make 1.7 an official release for some time. For the official release, please stick to 1.5. You can create update packages for 1.7 for your local installation, but let's wait a couple of days uploading 1.7 packages until Chris changed the release area to use unionfs. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Wed, Apr 16, 2008 at 11:39:16AM +0200, Corinna Vinschen wrote: On Apr 15 20:51, Lapo Luchini wrote: PS: my only WinXP box is still waiting for his motherboard back from RMA... I'll try qemu to test cygwin-1.7 and, if it's not too slow, produce updated packages for both 1.5 and 1.7 (or is 1.7 near enough that is better to update that first?). We will not make 1.7 an official release for some time. For the official release, please stick to 1.5. You can create update packages for 1.7 for your local installation, but let's wait a couple of days uploading 1.7 packages until Chris changed the release area to use unionfs. I played around a little more with this and found some problems that I have to investigate. When I move a file into the area from another directory it gives an error. That isn't really a big deal but I don't like putting things into production with known problems unless I have a vague understanding of the problem. So it will be a couple more days before I have the time to track this down. The size of this new, purged area is: 1926596K bytes. (I fixed my purge script) cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 14 19:24, Igor Peshansky wrote: Hmm. Even now, one does not have to edit the registry to switch from binary mode to text mode -- you just need to re-mount with the appropriate option. I assume the same will hold for the /etc/fstab approach. No, how should it? Of course you have to edit the fstab file to create a text mount from a binary mount, *iff* you want a persistent solution. mount(1) only creates temporary mount points who's life time is determined by the life time of the Cygwin processes in the current session. If we taught mount to do this now and removed the Text option from setup altogether, complainers could be directed to the mount manpage. Then switching to the new setup won't be that much of a pain (at least in the text/binary department). They will be directed to the user's guide. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 14 20:02, Brian Dessent wrote:
Christopher Faylor wrote:
Yes, I know. I just don't think it clarifies anything to put a Red
Hat in the registry.
I was thinking Cygwin would be better as well, but since it is
supposed to be a two-level heirarchy how about
HK{LM,CU}\Software\Cygwin Project\Cygwin. It has always seemed to me
that we actively try to de-emphasize any association that Red Hat has in
the actual day-to-day operation of the project, other than owning the
copyrights and having their own commercial fork. Likewise with the
Well, not exactly. I have done a lot of my 1.7 development lately on
blessed Red Hat time. The IPv6 changes and the long path name support
wouldn't be as progressed as they are if I hadn't got enough paid time
to do them. I don't think that deserves to be ignored.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 15 02:29, Brian Dessent wrote: Corinna Vinschen wrote: Having said that, should we really rename the registry keys, what do we do with the Program Options and the two heap_foo values? Should they be moved to the new registry key? If yes, should the postinstall script I created a couple of days ago also move them? For the heap_chunk settings, couldn't they simply be moved into $CYGWIN? Unfortunately, no. The environment initialization requires that the memory initialization has already be done. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen wrote: Having said that, should we really rename the registry keys, what do we do with the Program Options and the two heap_foo values? Should they be moved to the new registry key? If yes, should the postinstall script I created a couple of days ago also move them? For the heap_chunk settings, couldn't they simply be moved into $CYGWIN? Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 15 11:31, Corinna Vinschen wrote: On Apr 15 02:29, Brian Dessent wrote: Corinna Vinschen wrote: Having said that, should we really rename the registry keys, what do we do with the Program Options and the two heap_foo values? Should they be moved to the new registry key? If yes, should the postinstall script I created a couple of days ago also move them? For the heap_chunk settings, couldn't they simply be moved into $CYGWIN? Unfortunately, no. The environment initialization requires that the memory initialization has already be done. Of course, what we could do is to create a ../etc/cygwin.conf file which is read when the first cygwin process starts... Corinna
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 15 10:55, Corinna Vinschen wrote:
On Apr 14 20:02, Brian Dessent wrote:
Christopher Faylor wrote:
Yes, I know. I just don't think it clarifies anything to put a Red
Hat in the registry.
I was thinking Cygwin would be better as well, but since it is
supposed to be a two-level heirarchy how about
HK{LM,CU}\Software\Cygwin Project\Cygwin. It has always seemed to me
that we actively try to de-emphasize any association that Red Hat has in
the actual day-to-day operation of the project, other than owning the
copyrights and having their own commercial fork. Likewise with the
Well, not exactly. I have done a lot of my 1.7 development lately on
blessed Red Hat time. The IPv6 changes and the long path name support
wouldn't be as progressed as they are if I hadn't got enough paid time
to do them. I don't think that deserves to be ignored.
Having said that, should we really rename the registry keys, what do we
do with the Program Options and the two heap_foo values? Should
they be moved to the new registry key? If yes, should the postinstall
script I created a couple of days ago also move them?
Btw., I think the postinstall script as part of the Cygwin package was a
bad idea. I will create another package called base-cygwin which will
contain this script as well as a few scripts in /bin which allow users
to resurrect their HKCU keys and values.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Tue, Apr 15, 2008 at 11:08:49AM +0200, Corinna Vinschen wrote:
On Apr 15 10:55, Corinna Vinschen wrote:
On Apr 14 20:02, Brian Dessent wrote:
Christopher Faylor wrote:
Yes, I know. I just don't think it clarifies anything to put a Red
Hat in the registry.
I was thinking Cygwin would be better as well, but since it is
supposed to be a two-level heirarchy how about
HK{LM,CU}\Software\Cygwin Project\Cygwin. It has always seemed to me
that we actively try to de-emphasize any association that Red Hat has
in the actual day-to-day operation of the project, other than owning
the copyrights and having their own commercial fork. Likewise with the
Well, not exactly. I have done a lot of my 1.7 development lately on
blessed Red Hat time. The IPv6 changes and the long path name support
wouldn't be as progressed as they are if I hadn't got enough paid time
to do them. I don't think that deserves to be ignored.
Having said that, should we really rename the registry keys, what do we
do with the Program Options and the two heap_foo values?
I'd like to keep the Program Options and nuke the heap_foo options.
I also object to using Red Hat as the owner regardless of how much
paid work you've been able to do. I think it sends an extremely mixed
message for the public Cygwin project to be viewed as owned by Red Hat
while we solicit donations to help with development on the Cygwin web
site. I've been paid by a few companies to work on Cygwin and have been
spent long hours tracking down bugs for them. Additionally, most of the
work I have done for Cygwin in the past was done in my spare time even
when I was a paid employee
While I realize that you've spent quite a bit more time being paid by
Red Hat to make ipv6 and long path names work, I don't think that
necessarily translates into using Red Hat as the owner key in the
registry.
Also, given that this is a Windows project I have to wonder just how
much Red Hat would desire to have their names in the Windows Registry.
cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 15 10:17, Christopher Faylor wrote: On Tue, Apr 15, 2008 at 11:08:49AM +0200, Corinna Vinschen wrote: Having said that, should we really rename the registry keys, what do we do with the Program Options and the two heap_foo values? I'd like to keep the Program Options and nuke the heap_foo options. Maybe you can get rid of heap_chunk_in_mb but it's still not clear that we can get rid of heap_slop_in_mb. The strange allocation in 2003 and later is a problem and just because we had nobody complaining for a while doesn't mean the current slop value is always sufficient. I'm for keeping this option. I also object to using Red Hat as the owner [...] Red Hat *is* the owner of the code, regardless of the registry key you want to use. I know that you have mixed feelings about Red Hat, however, assuming the code is owned by the FSF, would you object against a parent key name of FSF as well? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
2008/4/15, Corinna Vinschen: On Apr 15 10:17, Christopher Faylor wrote: I also object to using Red Hat as the owner [...] Red Hat *is* the owner of the code, regardless of the registry key you want to use. I know that you have mixed feelings about Red Hat, however, assuming the code is owned by the FSF, would you object against a parent key name of FSF as well? Cannot we just use just Cygwin as the most obvious choice. We really don't have to use some artificial company name. -- Reini
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Tue, Apr 15, 2008 at 05:44:00PM +0200, Corinna Vinschen wrote: On Apr 15 10:17, Christopher Faylor wrote: On Tue, Apr 15, 2008 at 11:08:49AM +0200, Corinna Vinschen wrote: Having said that, should we really rename the registry keys, what do we do with the Program Options and the two heap_foo values? I'd like to keep the Program Options and nuke the heap_foo options. Maybe you can get rid of heap_chunk_in_mb but it's still not clear that we can get rid of heap_slop_in_mb. The strange allocation in 2003 and later is a problem and just because we had nobody complaining for a while doesn't mean the current slop value is always sufficient. I'm for keeping this option. I also object to using Red Hat as the owner [...] Red Hat *is* the owner of the code, regardless of the registry key you want to use. I know that you have mixed feelings about Red Hat, however, assuming the code is owned by the FSF, would you object against a parent key name of FSF as well? Ok, since my motives for having an opinion are in question, I will withdraw from the discussion, rather than spending time on pointless self-justification. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 15 13:59, Christopher Faylor wrote: On Tue, Apr 15, 2008 at 05:44:00PM +0200, Corinna Vinschen wrote: Red Hat *is* the owner of the code, regardless of the registry key you want to use. I know that you have mixed feelings about Red Hat, however, assuming the code is owned by the FSF, would you object against a parent key name of FSF as well? Ok, since my motives for having an opinion are in question, I will withdraw from the discussion, rather than spending time on pointless self-justification. I apologize for making this argument. It was needless, pointless and rude. Since everybody else seems to dislike the company name in the registry key, I will not further argue against using Cygwin Project\Cygwin or just Cygwin. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen wrote: I will not further argue against using Cygwin Project\Cygwin or just Cygwin. I guess the one name no one can strongly argue against is the one we're using right now: perfect or outdated as it may be, it has at least one reason to be (retro-compatibility). PS: my only WinXP box is still waiting for his motherboard back from RMA... I'll try qemu to test cygwin-1.7 and, if it's not too slow, produce updated packages for both 1.5 and 1.7 (or is 1.7 near enough that is better to update that first?). -- Lapo Luchini [EMAIL PROTECTED] (OpenPGP X.509) www.lapo.it (Jabber, ICQ, MSN)
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 4/15/2008 12:38 PM: | | Since everybody else seems to dislike the company name in the registry | key, I will not further argue against using Cygwin Project\Cygwin or | just Cygwin. I hate unnecessary spaces. Can we go with Cygwin rather than Cygwin Project, so that scripts using /proc/registry don't have to worry about the space? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgE+y0ACgkQ84KuGfSFAYByzgCcDyXFFF9/0lgFJjUD6kNt0UJK /gEAniAU01A0w3WdNHYy5eKPraNzoL2Q =kfbj -END PGP SIGNATURE-
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Eric Blake wrote:
I hate unnecessary spaces. Can we go with Cygwin rather than Cygwin
Project, so that scripts using /proc/registry don't have to worry about
the space?
The only reason I suggested Cygwin Project\Cygwin is that it's
supposed to be a two level hierarchy, company\product, matching the
current Cygnus Solutions\Cygwin arrangement.
However, after a quick jaunt through HKLM\Software on this machine I see
that there are a good number of programs that forego the two level
custom and just put keys under HKLM\Software\Foo. So, with that in
mind, are there any objections to simply HK{LM,CU}\Software\Cygwin?
Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 13 15:35, Christopher Faylor wrote: On Sun, Apr 13, 2008 at 11:42:46AM +0200, Corinna Vinschen wrote: We would need to transfer them to the new place or we stick to the Cygnus Solutions for backward compatibility. I'm not sure we still need the Program Options thingy. I never heard about anybody actually using heap_slop_in_mb and only fortran programmers seem to need heap_chunk_in_mb :) I use Program Options (since I invented it) but I'm probably the only person in the known universe to do so. Are you suggesting to remove the Program Options? I admit I never quite understood what to do with them which I couldn't put into a script. I'm all for changing the name from Cygnus Solutions to Red Hat, but OTOH I think keeping the name of the key is more hassle free. Can't it just be Cygwin rather than Cygnus Solutions or Red Hat? By definition the key under the Software key is supposed to be the company name, the next key is the product key, os it should contain the Red Hat *iff* we change it. I'm not sure, though, we should change it at all. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Mon, Apr 14, 2008 at 11:56:28AM +0200, Corinna Vinschen wrote: On Apr 13 15:35, Christopher Faylor wrote: On Sun, Apr 13, 2008 at 11:42:46AM +0200, Corinna Vinschen wrote: We would need to transfer them to the new place or we stick to the Cygnus Solutions for backward compatibility. I'm not sure we still need the Program Options thingy. I never heard about anybody actually using heap_slop_in_mb and only fortran programmers seem to need heap_chunk_in_mb :) I use Program Options (since I invented it) but I'm probably the only person in the known universe to do so. Are you suggesting to remove the Program Options? I admit I never quite understood what to do with them which I couldn't put into a script. ? Program Options are not intended to be put in a script. They are intended to be set once to cygwin environment variable settings and then forgotten. It's somewhat equivalent to setting a global cygwin environment variable and could be used to set a per-system or per-user policy. I'm all for changing the name from Cygnus Solutions to Red Hat, but OTOH I think keeping the name of the key is more hassle free. Can't it just be Cygwin rather than Cygnus Solutions or Red Hat? By definition the key under the Software key is supposed to be the company name, the next key is the product key, os it should contain the Red Hat *iff* we change it. I'm not sure, though, we should change it at all. Yes, I know. I just don't think it clarifies anything to put a Red Hat in the registry. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Sat, 12 Apr 2008, Brian Dessent wrote: Unresolved issues with this plan: - What are we going to do about text/binary mode? To maintain the setting, setup would have to be taught to parse/write fstab. Ugh. Plan B would be to say that if you want textmode you have to edit fstab yourself. That has the advantage of making it harder to use textmode, which leads to fewer bugreports. On the other hand, the small army of insane people that do actually use textmode will probably be mad that they have to manually edit config files (the horror!) because the setup tool no longer has a choice. Hmm. Even now, one does not have to edit the registry to switch from binary mode to text mode -- you just need to re-mount with the appropriate option. I assume the same will hold for the /etc/fstab approach. It might make it easier if mount understood absolute POSIX paths as well (i.e., mount -t /etc/text /etc/text should work). If we taught mount to do this now and removed the Text option from setup altogether, complainers could be directed to the mount manpage. Then switching to the new setup won't be that much of a pain (at least in the text/binary department). - Do we really want to pick a new key for $newkey, or wedge it into the same existing location somehow? I admit that I do find it a bit silly that Cygwin still installs under Cygnus Solutions, and since a 1.7 DLL will not even look at the registry I guess it is proper to move to a totally new key for this setting. And of course for the 1.7 testing period we'd want it to be separate. But I mean long term, are we making 3rd parties lives easier or harder by having two totally different places/formats to check for an existing install of Cygwin? I agree that naming the new key Cygnus Solutions is silly, beyond certain nostalgic value. But one thing to consider is that by adding a registry key, we're setting things up for one dominant installation of Cygwin. So people juggling multiple installations really *will* have to go edit the registry to switch -- no more nice mount -m approach, since the mounts will no longer apply anyway. Also, things like heap_chunk_in_mb currently live in the registry. Will they stay there? Will we instead have /etc/cygwinopts (or move it to $CYGWIN)? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! That which is hateful to you, do not do to your neighbor. That is the whole Torah; the rest is commentary. Go and study it. -- Rabbi Hillel
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Christopher Faylor wrote:
Yes, I know. I just don't think it clarifies anything to put a Red
Hat in the registry.
I was thinking Cygwin would be better as well, but since it is
supposed to be a two-level heirarchy how about
HK{LM,CU}\Software\Cygwin Project\Cygwin. It has always seemed to me
that we actively try to de-emphasize any association that Red Hat has in
the actual day-to-day operation of the project, other than owning the
copyrights and having their own commercial fork. Likewise with the
Company ID in the resource strings for cygwin1.dll, listing Red Hat
always seemed a bit off to me, but I recognise that if we have to list a
real company that Red Hat is the obvious choice.
Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Igor Peshansky wrote: But one thing to consider is that by adding a registry key, we're setting things up for one dominant installation of Cygwin. So people juggling multiple installations really *will* have to go edit the registry to switch -- no more nice mount -m approach, since the mounts will no longer apply anyway. Can you clarify what you mean here? I don't understand. You're talking about maintaining separate installs, but part of the plan for setup.exe that I outlined supports this directly by the fact that if you change the value of the root install dir at step 2, setup then forgets anything it knew about the previous value, enabling you to keep around as many parallel installs as you want. Or do you mean keeping around an old-style 1.5 tree and a new-style 1.7 tree simultaneously? In that case you'd be using the old setup.exe (which doesn't know a thing about $newkey) for the 1.5 tree so I still don't see any conflict. Where does the need to edit the registry manually arise? Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 12 23:43, Christopher Faylor wrote:
On Fri, Apr 11, 2008 at 05:13:33PM +0200, Corinna Vinschen wrote:
I've now created a release-2 area. I used a somewhat intermediary
approach. The dirs are real dirs, the tar.bz2 files are symlinks
to the release area, the setup.hint and md5.sum files are copies.
The cygwin subdir only contains 1.7.0-1 packages.
Chris, could you please set up another upset which creates the
corresponding setup-2.{bz2,ini} files?
I have another way to do this using a union fs. Using a union fs means
that we can have a cygwin-2 directory which mirrors the old cygwin
directory, gaining the benefits of hardlinking, but also allowing
removals in the new directory without affecting the old cygwin
directory.
[...]
The only downside to this is that the mirrors will apparently be copying
all of the data twice.
That's what I was trying to avoid. In the long run you will have
two separate areas but the load of the mirroring is stretched out
over time. Probably I'm just still living in modem times...
all of the data twice. So, we could remove all of the obsolete files
and older revisions from this new release directory to minimize the
extra copying.
That might help a lot. If every package dir only contains the latest
versions you would have less than half the size. The only problem
would be that you have to grep the setup.hint files and remove
potential version information.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 13 00:44, Christopher Faylor wrote: I added setup-2.ini creation to the Makefile which creates setup.ini. (and commented out the cron entry that you had which was also doing this) Thanks, I removed the crontab entry entirely. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 12 16:02, Brian Dessent wrote:
Here's what I had in mind for the logic:
On startup, setup looks for $newkey. If found, it uses the Win32 path
stored there as the starting value for the root dir/install location.
If not found, it looks at $oldkey. If that's not found, it uses a
default of c:\cygwin.
In any case, if the user changes this value on the second step of the
installer, that new value becomes the effective value immediately;
anything obtained from the first value should be discarded. Access to
files in the POSIX namespace is done purely relative to this root, e.g.
setup creates an internal mount table of its own that maps the install
dir to / (and for the time being duplicating /{bin,lib} to
/usr/{bin,lib}, subject to change as well.) At the end of setup, the
effective value of the root dir is written out to $newkey.
Where:
newkey = some new key whose location is yet to be decided
oldkey = the location corresponding to the root dir of the current
registry mount table
In both of the above there is the implicit notion of looking first in
HKLM\Software and then falling back to HKCU\Software if not found,
allowing the non-admin user to install Cygwin as they please. The
location where it was found is used as the starting value for
justme/allusers, and if the user modifies the setting during the run the
resulting destination at the end is changed accordingly.
Sounds very reasonable. The just me would only decide about the
setup registry key and the place where the Cygwin desktop shortcut and
menu entries are created.
Unresolved issues with this plan:
- What are we going to do about text/binary mode? To maintain the
setting, setup would have to be taught to parse/write fstab. Ugh. Plan
B would be to say that if you want textmode you have to edit fstab
yourself. That has the advantage of making it harder to use textmode,
I made a quick poll in my neighborhood:
Plan A - 0 votes
Plan B - 1 vote
What the hell are you talking about? - 7 votes
So I think Plan B is the clear winner.
which leads to fewer bugreports. On the other hand, the small army of
insane people that do actually use textmode will probably be mad that
they have to manually edit config files (the horror!) because the setup
tool no longer has a choice.
I'm not exactly concerned.
- Do we really want to pick a new key for $newkey, or wedge it into the
same existing location somehow? I admit that I do find it a bit silly
that Cygwin still installs under Cygnus Solutions, and since a 1.7 DLL
will not even look at the registry I guess it is proper to move to a
totally new key for this setting. And of course for the 1.7 testing
period we'd want it to be separate. But I mean long term, are we making
3rd parties lives easier or harder by having two totally different
places/formats to check for an existing install of Cygwin?
The registry mount table is supposed to go away. If you look into the
new postinstall script in the cygwin sources, there's (commented out)
code which reads the old registry keys and converts them to fstab
entries. I'm planning to use the same code in another script which can
be called by /etc/profile and friends, to create the user specific fstab
file on the fly from the existing registry entries. What's missing
right now is the code to remove the old registry keys. But I guess I
will add that, too.
So we're at the point to ask what's the name of the new registry key
should be. Here's still a problem: The registry is also used for other
purposes:
Program Options (Special $CYGWIN settings per application)
heap_chunk_in_mb
heap_slop_in_mb
We would need to transfer them to the new place or we stick to the
Cygnus Solutions for backward compatibility. I'm not sure we still
need the Program Options thingy. I never heard about anybody actually
using heap_slop_in_mb and only fortran programmers seem to need
heap_chunk_in_mb :)
I'm all for changing the name from Cygnus Solutions to Red Hat, but
OTOH I think keeping the name of the key is more hassle free.
I'd suggest to use simply a subkey of the existing Cygwin key:
{HKLM,HKCU}/Software/Cygnus Solutions/Cygwin/setup-${versioninfo}/
You could use a string value called install_root and possibly others
as you see fit since only setup would use them at all. ${versioninfo}
should probably begin with 2.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Sun, Apr 13, 2008 at 11:42:46AM +0200, Corinna Vinschen wrote: We would need to transfer them to the new place or we stick to the Cygnus Solutions for backward compatibility. I'm not sure we still need the Program Options thingy. I never heard about anybody actually using heap_slop_in_mb and only fortran programmers seem to need heap_chunk_in_mb :) I use Program Options (since I invented it) but I'm probably the only person in the known universe to do so. I'm all for changing the name from Cygnus Solutions to Red Hat, but OTOH I think keeping the name of the key is more hassle free. Can't it just be Cygwin rather than Cygnus Solutions or Red Hat? cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Sun, Apr 13, 2008 at 11:03:14AM +0200, Corinna Vinschen wrote:
On Apr 12 23:43, Christopher Faylor wrote:
On Fri, Apr 11, 2008 at 05:13:33PM +0200, Corinna Vinschen wrote:
I've now created a release-2 area. I used a somewhat intermediary
approach. The dirs are real dirs, the tar.bz2 files are symlinks
to the release area, the setup.hint and md5.sum files are copies.
The cygwin subdir only contains 1.7.0-1 packages.
Chris, could you please set up another upset which creates the
corresponding setup-2.{bz2,ini} files?
I have another way to do this using a union fs. Using a union fs means
that we can have a cygwin-2 directory which mirrors the old cygwin
directory, gaining the benefits of hardlinking, but also allowing
removals in the new directory without affecting the old cygwin
directory.
[...]
The only downside to this is that the mirrors will apparently be copying
all of the data twice.
That's what I was trying to avoid. In the long run you will have
two separate areas but the load of the mirroring is stretched out
over time. Probably I'm just still living in modem times...
all of the data twice. So, we could remove all of the obsolete files
and older revisions from this new release directory to minimize the
extra copying.
That might help a lot. If every package dir only contains the latest
versions you would have less than half the size. The only problem
would be that you have to grep the setup.hint files and remove
potential version information.
Actually the difference is 3122332 purged vs. 4640060 unpurged.
I am not sure how much to worry about the effect on the mirrors. It
seems like there would be an additional flurry of activity that would
eventually just die down. I hate to make supportability decisions based
on external constraints.
That does raise the issue of the mirror checking software that runs to
make sure that a mirror is valid. It seems like that may need to be
tweaked no matter what we do.
cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Sun, Apr 13, 2008 at 11:04:42AM +0200, Corinna Vinschen wrote: On Apr 13 00:44, Christopher Faylor wrote: I added setup-2.ini creation to the Makefile which creates setup.ini. (and commented out the cron entry that you had which was also doing this) Thanks, I removed the crontab entry entirely. I had to tweak this further because the two runs were stomping on each other changing the packages directory back and forth between release and release-2. So, I've created a 'packages-2' directory which can be used to search for packages in the -2 directory and modified upset to optionally generate this directory. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 11 18:47, Brian Dessent wrote:
Corinna Vinschen wrote:
Brian, could you please prepare a temporary setup-1.7.exe which
only downloads from the release-2 area?
Okay, I uploaded http://cygwin.com/setup-1.7.exe which fetches
setup-2.{ini,bz2}. It identifies itself as version 2.590-1.7special on
the splash page so that we can tell it apart from the normal.
Cool, thanks! I've set up a cronjob which updates setup-2.{ini, bz2}
every hour for now. I also corrected a dumb mistake I made when
creating the release-2 area. The symlinks were all broken on the
mirrors because they were creatd as absolute paths. I re-created the
release-2 area with correct relative symlinks to the release area now.
I guess we'll wait a day until this all settles on the mirrors and
then I'll create an announcement for the developers and package
maintainers.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 12 13:35, Corinna Vinschen wrote:
On Apr 11 18:47, Brian Dessent wrote:
Corinna Vinschen wrote:
Brian, could you please prepare a temporary setup-1.7.exe which
only downloads from the release-2 area?
Okay, I uploaded http://cygwin.com/setup-1.7.exe which fetches
setup-2.{ini,bz2}. It identifies itself as version 2.590-1.7special on
the splash page so that we can tell it apart from the normal.
Cool, thanks! I've set up a cronjob which updates setup-2.{ini, bz2}
every hour for now. I also corrected a dumb mistake I made when
creating the release-2 area. The symlinks were all broken on the
mirrors because they were creatd as absolute paths. I re-created the
release-2 area with correct relative symlinks to the release area now.
I guess we'll wait a day until this all settles on the mirrors and
then I'll create an announcement for the developers and package
maintainers.
There's a problem, Brian.
I updated my local mirror for a test run.
When I start setup-1.7, it seems to find the already existing c:/cygwin
installation. Even though I choose C:/cygwin-2 as installation path,
the new setup-2.ini content is compared against the already existing
installation. The result is that setup-1.7 offers to install only
the single changed package: cygwin itself.
Why is setup using the information from the existing installation
even if I choose to install into another directory? Is it because
the mount points in the registry are looked at? That's not correct
anymore, given that the registry mount points are not used for the
new installation anyway.
Is it possible to change setup so that it ignores the registry mount
points? And it must nort write new ones either, btw...
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen writes: I guess we'll wait a day until this all settles on the mirrors and then I'll create an announcement for the developers and package maintainers. An updated maintainerlist would also be handy ... Thanks, Corinna Ciao Volker
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 12 14:23, Dr. Volker Zell wrote: Corinna Vinschen writes: I guess we'll wait a day until this all settles on the mirrors and then I'll create an announcement for the developers and package maintainers. An updated maintainerlist would also be handy ... http://cygwin.com/cygwin-pkg-maint Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen wrote: When I start setup-1.7, it seems to find the already existing c:/cygwin installation. Even though I choose C:/cygwin-2 as installation path, the new setup-2.ini content is compared against the already existing installation. The result is that setup-1.7 offers to install only the single changed package: cygwin itself. Right, it reads /etc/setup/installed.db (where /etc is derived from the mount table) to see what the current versions are. Why is setup using the information from the existing installation even if I choose to install into another directory? Is it because the mount points in the registry are looked at? That's not correct anymore, given that the registry mount points are not used for the new installation anyway. Is it possible to change setup so that it ignores the registry mount points? And it must nort write new ones either, btw... Oh. Teaching it not to read or write to the mount table in the registry is going to be a lot more work than just telling it to read a different .ini file. I'll see what I can do, but until then I think we'll just have to tell people to do the switching manually (mount -m/umount -A). Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 12 05:45, Brian Dessent wrote: Corinna Vinschen wrote: When I start setup-1.7, it seems to find the already existing c:/cygwin installation. Even though I choose C:/cygwin-2 as installation path, the new setup-2.ini content is compared against the already existing installation. The result is that setup-1.7 offers to install only the single changed package: cygwin itself. Right, it reads /etc/setup/installed.db (where /etc is derived from the mount table) to see what the current versions are. Why is setup using the information from the existing installation even if I choose to install into another directory? Is it because the mount points in the registry are looked at? That's not correct anymore, given that the registry mount points are not used for the new installation anyway. Is it possible to change setup so that it ignores the registry mount points? And it must nort write new ones either, btw... Oh. Teaching it not to read or write to the mount table in the registry is going to be a lot more work than just telling it to read a different .ini file. I'll see what I can do, but until then I think we'll just have to tell people to do the switching manually (mount -m/umount -A). Thank you. I also found, when setup doesn't have the mount points it doesn't seem to be able to take the /etc/setup/installed.db from the path entered as root directory. It installs happily all base packages again a second time. Probably we will still need *some* registry entry. Setup could create one for its own purpose, just to find the installation path. Maybe the registry value should use a version number, so that we can have two parallel installation again, should we ever release a -3 distro... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 4/12/2008 9:15 AM: | | Probably we will still need *some* registry entry. Setup could create | one for its own purpose, just to find the installation path. I agree. Besides, based on the question on the main list - how is an independent distributor supposed to know if cygwin is installed, so they don't become a 3PP? If we have something in the registry, the answer is obvious - cygwin is installed. If we don't, then they have to hunt for likely candidate locations (and will probably guess wrong, becoming a 3PP even though they were trying to play nice and search for a previous installation). | Maybe the | registry value should use a version number, so that we can have two | parallel installation again, should we ever release a -3 distro... I think we need a version number, and a directory where the installation was done. But we don't need a full mount table. And I think it is still conceivable that cygwin1.dll does not have to refer to the registry, just setup.exe. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgA9TkACgkQ84KuGfSFAYBX5ACdEHk5SV36EMLHxw1rQCfNwPo8 xZkAoIA1a0pDIBkN9D6/cKLeCxCN6AQc =x7b6 -END PGP SIGNATURE-
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen wrote:
I also found, when setup doesn't have the mount points it doesn't seem
to be able to take the /etc/setup/installed.db from the path entered as
root directory. It installs happily all base packages again a second
time.
Probably we will still need *some* registry entry. Setup could create
one for its own purpose, just to find the installation path. Maybe the
registry value should use a version number, so that we can have two
parallel installation again, should we ever release a -3 distro...
Here's what I had in mind for the logic:
On startup, setup looks for $newkey. If found, it uses the Win32 path
stored there as the starting value for the root dir/install location.
If not found, it looks at $oldkey. If that's not found, it uses a
default of c:\cygwin.
In any case, if the user changes this value on the second step of the
installer, that new value becomes the effective value immediately;
anything obtained from the first value should be discarded. Access to
files in the POSIX namespace is done purely relative to this root, e.g.
setup creates an internal mount table of its own that maps the install
dir to / (and for the time being duplicating /{bin,lib} to
/usr/{bin,lib}, subject to change as well.) At the end of setup, the
effective value of the root dir is written out to $newkey.
Where:
newkey = some new key whose location is yet to be decided
oldkey = the location corresponding to the root dir of the current
registry mount table
In both of the above there is the implicit notion of looking first in
HKLM\Software and then falling back to HKCU\Software if not found,
allowing the non-admin user to install Cygwin as they please. The
location where it was found is used as the starting value for
justme/allusers, and if the user modifies the setting during the run the
resulting destination at the end is changed accordingly.
The above is meant to achieve the following objectives:
- the setup tool and other 3rd party tools have a key telling if Cygwin
is installed and where
- at startup setup can find its last-* from the last run and use them as
defaults so that the user doesn't have to re-enter them every time
- installing multiple trees becomes a matter of simply changing the root
dir at step 2 of the install process
Unresolved issues with this plan:
- What are we going to do about text/binary mode? To maintain the
setting, setup would have to be taught to parse/write fstab. Ugh. Plan
B would be to say that if you want textmode you have to edit fstab
yourself. That has the advantage of making it harder to use textmode,
which leads to fewer bugreports. On the other hand, the small army of
insane people that do actually use textmode will probably be mad that
they have to manually edit config files (the horror!) because the setup
tool no longer has a choice.
- Do we really want to pick a new key for $newkey, or wedge it into the
same existing location somehow? I admit that I do find it a bit silly
that Cygwin still installs under Cygnus Solutions, and since a 1.7 DLL
will not even look at the registry I guess it is proper to move to a
totally new key for this setting. And of course for the 1.7 testing
period we'd want it to be separate. But I mean long term, are we making
3rd parties lives easier or harder by having two totally different
places/formats to check for an existing install of Cygwin?
Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Fri, Apr 11, 2008 at 05:13:33PM +0200, Corinna Vinschen wrote:
On Apr 9 18:28, Corinna Vinschen wrote:
On Apr 9 10:31, Christopher Faylor wrote:
On Wed, Apr 09, 2008 at 06:09:46AM -0700, Brian Dessent wrote:
Corinna Vinschen wrote:
My favorite would be release-2. It has nothing to do with the DLL
Sounds fine to me as well.
It's ok.
Oh, btw., can we really just use symlinks to the top-level dirs?
It just occured to me that some package directories contain
subdirectories for packages which are maintained by another
maintainer. For instance the perl and python subdirs...
I've now created a release-2 area. I used a somewhat intermediary
approach. The dirs are real dirs, the tar.bz2 files are symlinks
to the release area, the setup.hint and md5.sum files are copies.
The cygwin subdir only contains 1.7.0-1 packages.
Chris, could you please set up another upset which creates the
corresponding setup-2.{bz2,ini} files?
I have another way to do this using a union fs. Using a union fs means
that we can have a cygwin-2 directory which mirrors the old cygwin
directory, gaining the benefits of hardlinking, but also allowing
removals in the new directory without affecting the old cygwin
directory.
I set up a release-2008 directory briefly under
/sourceware/ftp/anonftp/pub/cygwin where I've removed all of the
cygwin-1.5* files from the cygwin directory, left the existing
setup.hint, and put cygwin-1.7* files there. The directory now contains
the actual setup.hint from /sourceware/ftp/anonftp/pub/cygwin and
the new files that are unique.
The only downside to this is that the mirrors will apparently be copying
all of the data twice. So, we could remove all of the obsolete files
and older revisions from this new release directory to minimize the
extra copying.
I've always wanted to use a union fs and I think that, except for the
hit on the mirrors, this is going to be the most problem free way of
maintaining a separate build area.
cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Fri, Apr 11, 2008 at 05:13:33PM +0200, Corinna Vinschen wrote:
On Apr 9 18:28, Corinna Vinschen wrote:
On Apr 9 10:31, Christopher Faylor wrote:
On Wed, Apr 09, 2008 at 06:09:46AM -0700, Brian Dessent wrote:
Corinna Vinschen wrote:
My favorite would be release-2. It has nothing to do with the DLL
Sounds fine to me as well.
It's ok.
Oh, btw., can we really just use symlinks to the top-level dirs?
It just occured to me that some package directories contain
subdirectories for packages which are maintained by another
maintainer. For instance the perl and python subdirs...
I've now created a release-2 area. I used a somewhat intermediary
approach. The dirs are real dirs, the tar.bz2 files are symlinks
to the release area, the setup.hint and md5.sum files are copies.
The cygwin subdir only contains 1.7.0-1 packages.
Chris, could you please set up another upset which creates the
corresponding setup-2.{bz2,ini} files?
I added setup-2.ini creation to the Makefile which creates setup.ini.
(and commented out the cron entry that you had which was also doing
this)
cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 9 18:28, Corinna Vinschen wrote:
On Apr 9 10:31, Christopher Faylor wrote:
On Wed, Apr 09, 2008 at 06:09:46AM -0700, Brian Dessent wrote:
Corinna Vinschen wrote:
My favorite would be release-2. It has nothing to do with the DLL
Sounds fine to me as well.
It's ok.
Oh, btw., can we really just use symlinks to the top-level dirs?
It just occured to me that some package directories contain
subdirectories for packages which are maintained by another
maintainer. For instance the perl and python subdirs...
I've now created a release-2 area. I used a somewhat intermediary
approach. The dirs are real dirs, the tar.bz2 files are symlinks
to the release area, the setup.hint and md5.sum files are copies.
The cygwin subdir only contains 1.7.0-1 packages.
Chris, could you please set up another upset which creates the
corresponding setup-2.{bz2,ini} files?
Brian, could you please prepare a temporary setup-1.7.exe which
only downloads from the release-2 area?
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Forgive me, but I stopped following this thread a while back. I trust you all to work out the best method. When all of the issues are sorted out, can you please post a summary for package maintainers of what we need to do? Thanks, Andrew.
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 11 12:27, Andrew Schulman wrote: Forgive me, but I stopped following this thread a while back. I trust you all to work out the best method. When all of the issues are sorted out, can you please post a summary for package maintainers of what we need to do? Of course. I will send more details than you'll ever dreamed of in your worst nightmares. Dread the might of Cygwin, mortal! evil laughter Cough... sorry, I got carried away... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen wrote:
Brian, could you please prepare a temporary setup-1.7.exe which
only downloads from the release-2 area?
Okay, I uploaded http://cygwin.com/setup-1.7.exe which fetches
setup-2.{ini,bz2}. It identifies itself as version 2.590-1.7special on
the splash page so that we can tell it apart from the normal.
Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 8 16:27, Brian Dessent wrote: Corinna Vinschen wrote: Sorry, but I didn't remember that. Why didn't you just tell us? I thought we were talking about two different things. As I see it, here are the *conceptual* things we're dealing with: A) We want to have a tree of packages that is still usable for users of 9x/ME after 1.7 is released, even if it's not updated often or at all. Since setup can determine this at runtime, it can simply decide to fetch a different .ini. B) We want to have a playground where maintainers and advanced users can try out 1.7 and packages built against 1.7, in preparation for the release. C) During that prep period (i.e. right now) we want the standard 1.5 tree to remain and be the default for users. Now, having written that it appears that (A) and (C) are really the same thing. So maybe we only actually have two things: the current tree which will get renamed to _legacy after 1.7 is released, and a new playground which will be promoted to the standard release tree when 1.7 is ready and tested. That matches it. So it appears this is what we want: For right now/temporary: - standard setup.exe grabs setup.ini/bz2 for both 9x/ME and NT (i.e. no version checking code) - advanced user/maintainer setup.exe grabs setup-1.7.ini/bz2 unconditionally which will be a new tree we create, which contains packages built against 1.7 At point of 1.7 release: - rename setup.ini to setup_legazy.ini - rename setup-1.7.init to setup.ini - release new setup.exe that replaces both of the above, with 9x/ME check enabled (back to one version of setup.exe) Sound about right? Yes. I'm just wondering if we could do without the final rename of the directories. The Cygwin release area isn't that small, 4 Gigs. A simple top-level directory rename will force all mirrors world-wide to copy the whole area. Twice, because we will have two release areas. If that's a minor concern, we do as above. Otherwise, I'd suggest to create a release-2 area and to update just setup.exe accordingly. And yes, it's rather trivial to release a new setup.exe with the ini name tweaked, so once we decide on that I can upload such to the website. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen wrote: My favorite would be release-2. It has nothing to do with the DLL Sounds fine to me as well. Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 9 05:09, Brian Dessent wrote: Corinna Vinschen wrote: Yes. I'm just wondering if we could do without the final rename of the directories. The Cygwin release area isn't that small, 4 Gigs. A simple top-level directory rename will force all mirrors world-wide to copy the whole area. Twice, because we will have two release areas. If that's a minor concern, we do as above. Otherwise, I'd suggest to create a release-2 area and to update just setup.exe accordingly. We can still rename the .ini files without renaming the directory trees, it's all just a matter of how the upset cron job runs. I'm not sure if that really buys any clarity, but what it does do is allow us to swap in the entire staging area atomically once 1.7 is released. Otherwise, only users who updated their setup.exe would ever see the 1.7 release. I can almost see the email messages now: Is Cygwin dead? I haven't seen a new release of the DLL or any updated packages in the last nn months?!?! Ok, let's decide about renaming directories at some later point. For now, I will just create a second dir for the 1.7 test release. Last call for the right name: release-ng release-2 release-2008 release-1.7 My favorite would be release-2. It has nothing to do with the DLL version number, it's just release 2 of the net distro. I will happily use any other name as long as we can agree to take off in the next days. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Wed, Apr 09, 2008 at 06:09:46AM -0700, Brian Dessent wrote: Corinna Vinschen wrote: My favorite would be release-2. It has nothing to do with the DLL Sounds fine to me as well. It's ok. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Wed, 9 Apr 2008 10:31:39 -0400, Christopher Faylor wrote: On Wed, Apr 09, 2008 at 06:09:46AM -0700, Brian Dessent wrote: Corinna Vinschen wrote: My favorite would be release-2. It has nothing to do with the DLL Sounds fine to me as well. It's ok. Works for me. One question: the old plan was, as outlined by Brian, that we would eventually have: release_legacy -- renamed from existing 'release' directory release -- new 1.7 stuff, once it is gold. (and somewhere we would have a temp release-1.7/-2008/whatever thing, which would get renamed to 'release') Is the new plan: release -- stays exactly as is, forever and ever. (OK, maybe some pkg updates...) release-2 -- temp with custom setup.exe during development, but eventually becomes actual when (a) we decide that 1.7 and associated pkgs are ready to go (b) and we release a new setup.exe with the special are you Win9x--release (NOT release_legacy), else --release-2 That is, no directory renaming at all (which would make the mirrors happy) -- we activate by releasing a new setup? ? -- Chuck
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 9 11:04, Charles Wilson wrote: On Wed, 9 Apr 2008 10:31:39 -0400, Christopher Faylor wrote: On Wed, Apr 09, 2008 at 06:09:46AM -0700, Brian Dessent wrote: Corinna Vinschen wrote: My favorite would be release-2. It has nothing to do with the DLL Sounds fine to me as well. It's ok. Works for me. One question: the old plan was, as outlined by Brian, that we would eventually have: release_legacy -- renamed from existing 'release' directory release -- new 1.7 stuff, once it is gold. (and somewhere we would have a temp release-1.7/-2008/whatever thing, which would get renamed to 'release') Is the new plan: release -- stays exactly as is, forever and ever. (OK, maybe some pkg updates...) release-2 -- temp with custom setup.exe during development, but eventually becomes actual when (a) we decide that 1.7 and associated pkgs are ready to go (b) and we release a new setup.exe with the special are you Win9x--release (NOT release_legacy), else --release-2 That is, no directory renaming at all (which would make the mirrors happy) -- we activate by releasing a new setup? Yes! :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 9 10:31, Christopher Faylor wrote: On Wed, Apr 09, 2008 at 06:09:46AM -0700, Brian Dessent wrote: Corinna Vinschen wrote: My favorite would be release-2. It has nothing to do with the DLL Sounds fine to me as well. It's ok. Oh, btw., can we really just use symlinks to the top-level dirs? It just occured to me that some package directories contain subdirectories for packages which are maintained by another maintainer. For instance the perl and python subdirs... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 4 14:15, Corinna Vinschen wrote: On Apr 3 20:49, Christopher Faylor wrote: [responding to the thread which started it all] On Wed, Apr 02, 2008 at 02:35:51PM +0200, Corinna Vinschen wrote: - We create a ftp://cygwin.com/pub/cygwin-1.7 dir. - Under that dir, we create the full release directory structure as it exists in the parallel cygwin dir, except for the cygwin itself. So far so good. I'm just not sure we should really call it cygwin-1.7. What would be a good name, which does not refer to the actual version number? Cygwin with uppercase C? I'm volunteering to create the directory layout... - All files in the original release dir are hardlinked into their matching spot in the cygwin-1.7 dir. I don't like hardlinking. It's too easy to have unintended side effects. I think I'd rather just symlink the directories in the new release area then rm the symlink and create a new directory when it's time to populate the directory with a 1.7 version. In theory I agree, but it lets more room for mistakes. It's very easy to have a new package and just move the files to the directory, instead of checking if the directory is a symlink or a real dir. If the dir is a real dir from the start, you just dump the new package into the dir and remove the oldest files and be done. Anyway, it's nothing I really get excited about. ...using the directory symlink approach. Could one of the setup.exe guys then create a matching setup.exe binary? Please? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Tue, Apr 08, 2008 at 06:26:46PM +0200, Corinna Vinschen wrote: On Apr 4 14:15, Corinna Vinschen wrote: On Apr 3 20:49, Christopher Faylor wrote: [responding to the thread which started it all] On Wed, Apr 02, 2008 at 02:35:51PM +0200, Corinna Vinschen wrote: - We create a ftp://cygwin.com/pub/cygwin-1.7 dir. - Under that dir, we create the full release directory structure as it exists in the parallel cygwin dir, except for the cygwin itself. So far so good. I'm just not sure we should really call it cygwin-1.7. What would be a good name, which does not refer to the actual version number? Cygwin with uppercase C? I'm volunteering to create the directory layout... Too bad we can't call it cygwin2.dll. I don't think making it differ by case is a good idea. This is bound to cause problems for Windows somehow. cygwin-xp? cygwin-2008? cygwin-nextgen? cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 8 13:26, Christopher Faylor wrote: On Tue, Apr 08, 2008 at 06:26:46PM +0200, Corinna Vinschen wrote: On Apr 4 14:15, Corinna Vinschen wrote: On Apr 3 20:49, Christopher Faylor wrote: [responding to the thread which started it all] On Wed, Apr 02, 2008 at 02:35:51PM +0200, Corinna Vinschen wrote: - We create a ftp://cygwin.com/pub/cygwin-1.7 dir. - Under that dir, we create the full release directory structure as it exists in the parallel cygwin dir, except for the cygwin itself. So far so good. I'm just not sure we should really call it cygwin-1.7. What would be a good name, which does not refer to the actual version number? Cygwin with uppercase C? I'm volunteering to create the directory layout... Too bad we can't call it cygwin2.dll. I don't think making it differ by case is a good idea. This is bound to cause problems for Windows somehow. cygwin-xp? cygwin-2008? cysta? :) cygwin-2008 isn't bad, though. cygwin-nextgen? Or just cygwin-new, maybe. I'd take any of them, -new or -2008. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Tue, Apr 08, 2008 at 13:26:46 -0400, Christopher Faylor wrote: On Tue, Apr 08, 2008 at 06:26:46PM +0200, Corinna Vinschen wrote: I'm just not sure we should really call it cygwin-1.7. What would be a good name, which does not refer to the actual version number? Cygwin with uppercase C? I don't think making it differ by case is a good idea. This is bound to cause problems for Windows somehow. I agree. cygwin-xp? cygwin-2008? cygwin-nextgen? I'd lean towards cygwin-2008. As we have learned with the various Microsoft products, the year in a product or distribution name is only tangentially related to the product's lifespan, birthdate, or end-of-life. Plus using cygwin-2008 doesn't restrict us from continuing to use it with cygwin-1.9, cygwin-1.11, etc in the future -- unless we have a paradigm-breaking new release (again), like cygwin-1.7 is. I doubt such a thing would occur twice in one year. If we do choose to name the release directory cygwin-2008, we probably ought to try to get cygwin-1.7 out the door before, say, Christmas, tho. g -- Chuck
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Tue, Apr 08, 2008 at 07:40:13PM +0200, Corinna Vinschen wrote: On Apr 8 13:26, Christopher Faylor wrote: On Tue, Apr 08, 2008 at 06:26:46PM +0200, Corinna Vinschen wrote: On Apr 4 14:15, Corinna Vinschen wrote: On Apr 3 20:49, Christopher Faylor wrote: [responding to the thread which started it all] On Wed, Apr 02, 2008 at 02:35:51PM +0200, Corinna Vinschen wrote: - We create a ftp://cygwin.com/pub/cygwin-1.7 dir. - Under that dir, we create the full release directory structure as it exists in the parallel cygwin dir, except for the cygwin itself. So far so good. I'm just not sure we should really call it cygwin-1.7. What would be a good name, which does not refer to the actual version number? Cygwin with uppercase C? I'm volunteering to create the directory layout... Too bad we can't call it cygwin2.dll. I don't think making it differ by case is a good idea. This is bound to cause problems for Windows somehow. cygwin-xp? cygwin-2008? cysta? :) cygwin-2008 isn't bad, though. cygwin-nextgen? Or just cygwin-new, maybe. I'd take any of them, -new or -2008. In my experience, adding a new to any directory or file is a guaranteed way of ensuring that the name will not always be accurate. How about cygwinng? cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Tue, Apr 08, 2008 at 02:34:03PM -0400, Charles Wilson wrote: If we do choose to name the release directory cygwin-2008, we probably ought to try to get cygwin-1.7 out the door before, say, Christmas, tho. g Uh oh. I'm hyperventilating now. Actually, given what is going into cygwin-1.7, the directory probably should be called cygwin-corinna. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 8 14:41, Christopher Faylor wrote: On Tue, Apr 08, 2008 at 07:40:13PM +0200, Corinna Vinschen wrote: On Apr 8 13:26, Christopher Faylor wrote: cygwin-xp? cygwin-2008? cysta? :) cygwin-2008 isn't bad, though. cygwin-nextgen? Or just cygwin-new, maybe. I'd take any of them, -new or -2008. In my experience, adding a new to any directory or file is a guaranteed way of ensuring that the name will not always be accurate. Why, we could always name the next versions cygwin-newer, cygwin-evenmorenew, cygwin-newerthannew and cygwin-reallyreallynew-imeanit. How about cygwinng? With a dash? cygwin-ng? Like syslog-ng. I was going to suggest this too, but I didn't want to copy the naming too bluntly. I guess we should use cygwin-notasnewbutstillnewenough. I'm still more leaning towards cygwin-2008. You shouldn't have suggested the name. It's all your fault. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 8 14:43, Christopher Faylor wrote: On Tue, Apr 08, 2008 at 02:34:03PM -0400, Charles Wilson wrote: If we do choose to name the release directory cygwin-2008, we probably ought to try to get cygwin-1.7 out the door before, say, Christmas, tho. g Uh oh. I'm hyperventilating now. Actually, given what is going into cygwin-1.7, the directory probably should be called cygwin-corinna. Naah! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen wrote: Why, we could always name the next versions cygwin-newer, cygwin-evenmorenew, cygwin-newerthannew and cygwin-reallyreallynew-imeanit. How about cygwinng? With a dash? cygwin-ng? Like syslog-ng. I was going to suggest this too, but I didn't want to copy the naming too bluntly. I guess we should use cygwin-notasnewbutstillnewenough. I'm still more leaning towards cygwin-2008. You shouldn't have suggested the name. It's all your fault. Okay, so, several years ago setup.exe HEAD was modified to look for release and release_legacy as the base dirname for packages depending on whether it was running on 9x/ME or NT/2k/etc. I understand that having Cygwin 1.7 playground is a different concept, but why should it be handled differently? Why not release_1.7? This is all temporary anyway IIUC, since it's just for testing packages built with 1.7, which will eventually all be moved over into just plain release anyway, right? If this is *not* temporary then how does it fit into the idea of having a legacy 9x/ME area? Brian
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Tue, Apr 08, 2008 at 11:07:26PM +0200, Corinna Vinschen wrote: On Apr 8 14:41, Christopher Faylor wrote: On Tue, Apr 08, 2008 at 07:40:13PM +0200, Corinna Vinschen wrote: On Apr 8 13:26, Christopher Faylor wrote: cygwin-xp? cygwin-2008? cysta? :) cygwin-2008 isn't bad, though. cygwin-nextgen? Or just cygwin-new, maybe. I'd take any of them, -new or -2008. In my experience, adding a new to any directory or file is a guaranteed way of ensuring that the name will not always be accurate. Why, we could always name the next versions cygwin-newer, cygwin-evenmorenew, cygwin-newerthannew and cygwin-reallyreallynew-imeanit. How about cygwinng? With a dash? cygwin-ng? Like syslog-ng. I was going to suggest this too, but I didn't want to copy the naming too bluntly. We actually use ng internally to Netapp. I actually wanted to call my project either ds9 or voyager but I got vetoed. I guess we should use cygwin-notasnewbutstillnewenough. I'm still more leaning towards cygwin-2008. You shouldn't have suggested the name. It's all your fault. I hate the name! Hate it! But I don't really care. cygwin-2008 is fine with me. However, I predict that cgf-2012 will probably be grumbling about that name eventually. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 8 14:16, Brian Dessent wrote: Corinna Vinschen wrote: Why, we could always name the next versions cygwin-newer, cygwin-evenmorenew, cygwin-newerthannew and cygwin-reallyreallynew-imeanit. How about cygwinng? With a dash? cygwin-ng? Like syslog-ng. I was going to suggest this too, but I didn't want to copy the naming too bluntly. I guess we should use cygwin-notasnewbutstillnewenough. I'm still more leaning towards cygwin-2008. You shouldn't have suggested the name. It's all your fault. Okay, so, several years ago setup.exe HEAD was modified to look for release and release_legacy as the base dirname for packages depending on whether it was running on 9x/ME or NT/2k/etc. I understand Sorry, but I didn't remember that. Why didn't you just tell us? How do you differ the setup.ini files if you only have different release subdirs? setup_legacy.ini? that having Cygwin 1.7 playground is a different concept, but why should it be handled differently? Why not release_1.7? This is all temporary anyway IIUC, since it's just for testing packages built with 1.7, which will eventually all be moved over into just plain release anyway, right? If this is *not* temporary then how does it fit into the idea of having a legacy 9x/ME area? When I came up with that a couple of days ago, I thought it might be bad to rename the current release area for 1.5 so that it keeps working as is and downloading from the 1.7 release area requires to make the conscience choice to use the 1.7 setup. If we can do this with a release-1.7 plus a setup-1.7.ini file, than that's ok for me, too. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
