Re: Hello all
----- Original Message -----
From: "Mark Paulus" <email@example.com>
Sent: Friday, November 16, 2001 3:13 AM
Subject: Re: Hello all
> On Thu, 15 Nov 2001 09:58:59 +1100, Robert Collins wrote:
> 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.
There are several issues:
1) setup.exe is a small program. It needs to stay fairly small to be
effective. So backend database integration should be done via dlopen'ed
.dll's, rather than static linking (or tightly coded static linking).
However until the replace-open-files issue is solved, those .dll's
cannot be dependent on cygwin1.dll, so a 100% native port of dpkg would
be needed. (Likewise for rpm).
2) Much of the setup.exe functionality was funded by redhat. I rather
expect that any effort put in from there would be towards rpm rather
than dpkg. Regardless, making cygwin's backend database dpkg will
_require_ the buy-in of the Redhat folk. However a working prototype may
well make some difference :}.
3) Conversion. Careful migration would have to occur. Cygwin's user base
is in the 1000's already, and any mishap would be rather... bad.
4) open file replacement issues - direct ports of dpkg would fail rather
badly (assumptions about the ability to replace ash for example).
> This would seem to offer several benefits:
> 1: There already is an established policy for package porting and
> within a given release cycle.
> 2: The tools are already written and very rich in their
> 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
> code requiring development....
> 4: Quick access to security updates
> 5: Established practices and archive forums to distribution and
> updates and new packages.
Yes, yes, yes, yes, yes. There's a while bunch of reasons I like debian
+ dpkg, and these are included.
> The one major problem I see with this whole setup is the one you
> problem number 1, which is that Win32 won't allow for any interactions
> a file that is already opened, and this makes for some interesting
> in the area of updating/upgrading already running processes,
> the cygwin1.dll file. Additionally, there is the whole "chicken/egg"
> (How do you get/install dpkg to run dpkg to install dpkg.....)
Setup.exe solves that. It is already a bootstrap program. Having it
detect a non-installed system and download a hardcoded list of base
packages is approximately 100 lines of code IMO. IOW, trivial.