Re: Global 32/64 bit collision issues

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

On Thu, May 23, 2013 at 10:44:35AM +0200, Corinna Vinschen wrote:
>Hi guys,
>
>
>Yaakov brought this up in a private IRC conversation a couple of
>weeks ago, but I dismissed it at the time.  But I guess we have to
>discuss this.
>
>Consider somebody has 32 and 64 bit Cygwin installed in parallel.  At
>least for developers and package maintainers this won't be that
>uncommon.  Now, they will run in parallel just fine, and most of our
>packages don't do anything outside of the cygwin installation dir.
>
>However, there are a couple of packages which change the system on a
>global basis.  I see three groups here:
>
>1. Packages installing shortcuts in the start menu and/or desktop
>   (this includes setup itself).
>
>   #1 types could be solved rather easily if we attach a "64" to all the
>   created shortcuts.  But do we really want that, considering a setup
>   for a "normal" user with only a single installation?  What are the
>   trade-offs?
>
>2. Packages installing services.
>
>   #2 packages have a service name collision.  Obviously you can't
>   install two services called "cron".  Should the package install its
>   service under another name, again by just attaching a "64" to the
>   service name?
>
>   This would require to change the service installer scripts to check
>   on what platform they are running and then attaching the "64" suffix
>   if `uname -m' returns "x86_64".
>
>   An alternative would be to change cygrunsrv so that the 64 bit
>   version always attaches the "64" automatically.  While this is easy
>   to accomplish, I see a problem here because the name change is not
>   transparent to the user, nor to scripts.
>
>   Having said that, the name change from "cron" to "cron64" is also
>   kind of cumbersome.  Usually you only need one service, either the 32
>   or the 64 bit version, but not both.  So, do we want the name change
>   at all?
>
>   But what about cygserver?  Without cygserver there's no XSI IPC.
>   Even if we don't change the service names on a general basis,
>   shouldn't cygserver at least be available in parallel, using
>   different service names?
>
>3. Packages installing network services.
>
>   As for the #3 packages, they collide in another way as well since a
>   service is usually connected with a default port.  Sshd is expected
>   on port 22.  Telnet on port 23, smtp on port 25, etc.  I don't think
>   it would be the right thing to move all 64 bit server to other ports
>   by default.  I don't see any satisfactory way to install those
>   services in parallel with a simple installer script, so I would keep
>   this to the knowledgable user.  And here it might be even helpful
>   that the service names already collide since it disallows to install
>   two network services 
>
>
>Right?  Wrong?  Neither right nor wrong?

Some of this is has got to be "the user has to know what they're doing".

They obviously just *can't* install two different telnet or smtp servers,
any more than they could have both a windows telnet server and a cygwin
one.  They would have to choose.

For services, isn't there some other field besides just the name which
can be used as a delineator?

For shortcuts, I don't see anything wrong with adding a "Cygwin 64" to
the name.