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


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

Global 32/64 bit collision issues


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?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat


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