This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


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

RE: SETUP WIZARD FOR CYGWIN?XFREE86


>
> Hi
>
> I currently don't have any spesific plan. There are some notes below,
> though...
>
Why you don't put this on the mailing list, I think there are some idea that
would be interessant for others ?

> On Tue, 24 Jul 2001, Ralf Habacker wrote:
>
> > > On Tue, 24 Jul 2001, Ralf Habacker wrote:
> > >
>
> > > Currently it seems to me that the best would be for every project to add
> > > their own cygwin packages,
> >
> > in some points I agree with you, I have added some necessary libs like
> > png,tiff,gif,zlib from a current cygwin distribution because for preventing
> > of version conflicts.
> > The cygwin library instead is contained only because of the next release
> > isn't ready yet and the current cygwin release would cause much support
> > requests. I don't like to support the cygwin dll as whole.
> >
> > > and hopefully those packages will make it into
> > > the contrib (and later: into stable) as fast as possible.
> >
> > Note that kde contains of about 10 tar balls and xfree as I remember more
> > than 30.
> > Add the estemmed 60 tar balls of the contrib and latest dir and place in on
> > simple list,
> > it's a nightmare to handle installation with the current installer.
>
> Partially because it does not remember what you chose last time.
>
> However, cygwin is indeed complex. Compare this to the components
> selection of MS's internet explorer (which is a far more homogenous
> system) and to the installation of linux distros.
>
> Asking every user to make a large number of selections is, of course, not
> a good idea. But you can have a number of ready-made selection parrtens in
> the installer. Simply using categories is not enough here, I believe.
>
Thats right. If I remenber right, this was dicussed already.

> I like the idea of debian's 'task' packages (packages that contain no
> files, and their only job is to help the user select a group of other
> packages through dependencies. This works well if you have a mechanism
> fordependencies, and for dependencies resolution :-( ).
>
> >
> > Additional this concept I think will be changed, because the cygwin
> > installer is going to get
> > categories and dependencies. Look at the cygwin and cygwin-patches
> > mailinglist for details.
> > So if this effort is ready I think the several projects can come together.
>
> Sorry. I don't have anything spesific in mind.
>
> >
> > > Thus the project will not have to worry about setup.exe , and will not
> > > have to worry about packages.
> >
> > I think setup.exe is the smallest problem. Currently it is quite easy to
> > install at first basic cygwin with all package you need, next xfree and
> > than any x-Apps.
>
> Installing is only the first part. What happens when I want to upgrade?
>
For kde 1.1.2 this weill be nnot problem because there are no update and Kde2
will be an independent port. For that, I think it could be handled by the
package
by itself.

> > In the last for example kde you can choose independed from the basic
> > installation, if cygwin reinstalling is needed or not.
> > Additional making a distribution like ke-cygwin isn't easy. There are many
> > dependencies and handling with own setup makes it simplier to create.
> > Assume that the kde installer is an additional window of the main
> > installer.
>
> It is easy to create. But it is pain for the user to recover from an
> incorrect "setup.exe" later.
>
> > Third my proposal relating the setup.exe is temporally because [3] kde isn't
> > integrated in the main cygwin distribution channels.
> > >
> > > The "SETUP.EXE" concept is nice, but cygwin is too complex for a simple
> > > installer that is not aware of the current system and the components that
> > > are already installed on it.

> >
> > I suppose you mean with setup.exe a normal windows setup.exe like install
> > shield or so ?
>
> Yes
>
> > Because the cygwin installer is able to recognize the installation state of
> > the current system
> > and components.
> >
> > How will your setup.exe handle upgrading?
> > Now I'm sure, you have misunderstood me, with setup I mean the normal cygwin
> > installer.
>
> I don't have anything spesific in mind...
>
> >
> > > (e.g.: are there certain config files that need to be saved?) removal? (I
> > > don't want the cyrillic fonts and the japanese documentation anymore. How
> > > do I remove them?)
> > A few weeks ago I have asked about a generic pre/postinstall/removal in the
> > cygwin installer.
> > This would handle this.
>
> While pre- and post-install scripts are very helpful, they are also
> problematic to write. BTW: rpm has for scripts: one before/after
> installation and before/after removal . Some of them are given diffeent
> arguments if the package is currently updated (and not newely installed).
>
> I'm not sure exactly about other packaging formats, but at least rpm
> handles config files explicitly (without the install script handling it):
>
> * The package creator marks certain files as "config" The user is
>   generallly allowed to edit those files (and only those files).
> * When "Installing" a package, all existing files are overridden.
> * When "upgrading" a package: if a certain config file has changed, then
>   it is saved, and the newer file is created with .rpmnew added.
>   If a file that is not a config file has changed since the package
>   installtion, then it is renamed to *.rpmorig and the new file takes its
>   place.
>
> (Chances are you already know that. Just in case...)

I know and like that and have placed a corresponding proposal in the cygwin
mailing list.
But creating rpm packages is not easy.
>
> > >
> > > So, you see, there is no point in replicating the exiting package
> > > instllation tool (although it can probably be improved).
> > This need that [3] is done, so as long as kde is distributed for his own,
> > this isn't right.
> > And second in the meantime, assume that the kde installer is an additional
> > window of the main
> > installer. Where is the problem ?
>
> What about batch installation?

Where is the problem, you can have the source of the installer. Create a new
main file
with option handling, call the available functions and it will work :-)

>
> If someone were to write a command-line front-end to the cygwin installer?
>
I don't know.
> >
> > > All you need is to seperate the files that are installed by the XFree
> > > installer into
> > > seperate "packages", each in its own tree, pack them as cygwin packages
> > > (simply tar balls of a partials trees) and create an appropriate
> > > setup.ini.
>
> In my original post I forgot to add something that would imply some irony
> (I know well that this is a lot of work, not to mention technical
> problems). Sorry.
>
> >
> > Think about that I have ported qt and kde-1.1.2 alone and made an
> > distribution and patched ld
> > and libtool and .... in two month, which was a heavy job, so if you get
> > profit from using kde,
> > spend some time to catch this aim.
> >
> > Thats the way open source works.
>
> --
> Tzafrir Cohen
> mailto:tzafrir@technion.ac.il
> http://www.technion.ac.il/~tzafrir
>
>


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