[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hello all



On Thu, 15 Nov 2001 09:58:59 +1100, Robert Collins wrote:

>
>1) Replacing open files. Say that setup uses berkley db3 as a .dll.
>Setup can not replace that .dll itself - and any dpkg/rpm style port
>will assume that it can replace that .dll. I've made a beta release of
>setup.exe that *can* do this, but it needs testing and work.
>2) Porting issues. Setup.exe is a win32 program, not a cygwin program.
>It could dynamically open cygwin1.dll, once it's been installed, but the
>core functionality, to grab packages off the net and install cygwin1.dll
>in the correct place with the correct permissions has to be built in.
>Thus any dpkg port that will bootstrap debian-w32 needs to be a native
>win32 program, statically linked to any libraries, and able to bootstrap
>itself to get any required .dll's.
>
>I think it would be a shame for users to have to bootstrap cygwin from
>cygwin.com, and then grab a *different* installer for debian-w32. IMO
>setup.exe should be a direct bootstrap. Also I think that maintaining a
>separate tree of binaries and source does not make sense for Cygwin
>today. There simply are not enough kernel developers or package
>maintainers at this point. It would be great to see some of the debian
>features and capabilities brought to the existing environment IMO.

In the interests of honest discussion, I'm wondering what would be
the problem with having cygwin's setup using dpkg/apt as it's backend.
This would allow those users who like a graphical front end to use cygwin's
gui setup app.  And, those who are more comfortable with a CLI to use
the standard dselect/dpkg/apt interfaces.  

This would seem to offer several benefits:
1:  There already is an established policy for package porting and inclusion 
within a given release cycle.
2:  The tools are already written and very rich in their functionallity.
3:  The porting process is well defined and can be quickly and easily 
leveraged to include this new w32/un*x architecture (barring some new "glue"
code requiring development....
4:  Quick access to security updates
5:  Established practices and archive forums to distribution and delivery of
updates and new packages.

The one major problem I see with this whole setup is the one you listed as
problem number 1, which is that Win32 won't allow for any interactions with
a file that is already opened, and this makes for some interesting challenges
in the area of updating/upgrading already running processes, especially
the cygwin1.dll file.  Additionally, there is the whole "chicken/egg" problem.
(How do you get/install dpkg to run dpkg to install dpkg.....)



>
>(Can you tell I'm walking a thin line here ?)
>
>Anyway,
>just letting you know I'm interested in how this goes,
>Rob
>
>
>-- 
>To UNSUBSCRIBE, email to debian-win32-request@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>





Reply to: