Time for a new DLL release
Sat Apr 29 10:03:00 GMT 2000
On Fri, 28 Apr 2000 17:57:19 -0400, you wrote:
>At 05:40 PM 4/28/00, Chris Faylor wrote:
>>On Fri, Apr 28, 2000 at 02:31:20PM -0700, Mo DeJong wrote:
>> >If we could use RPMs to do the install, a GUI should be easy because it
>> >would just exec rpm. The only catch is how the system "knowns" what
>> >rpms need to be updated by new versions. We would need some automated
>> >way to figure this stuff out, it is not acceptable for people to "just
>> >know" which RPMS needed to be downloaded. At any rate, I am willing to
>> >help out on the GUI installer side.
>>Experience has shown me to run screaming in the other direction whenever
>>I hear someone say that "The GUI should just be easy."
>I don't pretend to be an RPM expert but it seems to me that both the issue
>of updating and the GUI issue should be addressed already. From what I've
>seen, RPM knows when a package or one of it dependencies is out of date.
>Unless I'm wrong, this should take care of the lion's share (if not all) of
>the concern about what needs updating. As for the GUI, there has been one
>(and now there's at least 2 with the advent of GNOME) that we could key off
>of. There may be issues with what the underlying GUI engine is (GTK, X,
>whatever) and that may make it difficult or otherwise undesirable to use
>but at the very least, it should be possible to at least "follow the pattern"
>to create a new GUI that suits any Cygwin specific need.
>Anyway, just a thought...
RPM itself does not really know if to update or not. But there are a
lot of scripts out there in linuxland that know precisely if a package
is newer or not because the version information in the rpm's
filnenames makes it easy to find out if the installed version is
newer/older than the one found somewhere (at least, most of the time
...) Porting / using such a script should be easy and sraightforward,
I will have a look at that tonight.
Thinking of gui's I'm not shure which way to go.
I have already built glib and gtk - rpm's for cygwin (gnome-libs et al
are also rpm'ized but do not work too well) so the way should
theoretically be open to port one of the gnome-rpm managers without
too much effort. Tools for KDE are not in reach now because qt does
not really port easy to cygwin.
The main disadvantage is that a lot of overhead has to be installed in
the first step before the gui for installation shows up. That is imho
a mayor disadvantage. Another one is that the cygwin dll has to stay
in memory and thus replacing it is a little more tricky (but not
impossible) A static version of cygwin dll would help a lot if we
would decide to go this way..
Writing a 'pure' Windows installer makes it possible to create a
single file with 'everythin included'. The problem of this approach is
that if it's a 100% pure windows application that does not use
cygwin's dll then there is a lot of code to be re-implemented to make
the rpm databases available to the setup program. 8-(
The best bet would perhaps be to create a windows installer that
interacts with rpm via a shell-script. The installer could check for
updates, rename/remove cygwin dll's if it needs to update the dll
itself, download the files and then let rpm do the work. (I think that
is pretty much simmilar to Mo's approach)
More information about the Cygwin-developers