Mail Archives: cygwin-apps/2001/07/24/09:06:56
----- Original Message -----
From: "Tzafrir Cohen" <tzafrir AT technion DOT ac DOT il>
> On Tue, 24 Jul 2001, Robert Collins wrote:
>
> >
> > Also there are now, or soon will be pre-remove scripts to remove config
> > files etc, and there are already post-install scripts to complete
> > configuration settings.
>
> why remove config files?
To use the debian terms - there is uninstall, where you are removing a
package, but ay reinstall, and there is purging, where you want no trace
left.
> What happens if I were to remove a package an then install it? Should it
> not keep my configuration?
What if you removed it because the configuration was corrupt? We don't
discrimate between purge and uninstall yet, so my example of removing config
files was hypothetical.
> (Those scripts _are_ needed, of course)
>
> I like the way rpm handles files through upgrades of packages.
Sure. rpm/ports/dpkg all handle upgrades quite well, AFAICT.
> > > I know and like that and have placed a corresponding proposal in the
> > > cygwin mailing list. But creating rpm packages is not easy.
> >
> > As cygwin doesn't have rpm support in the setup program, they are also
not
> > very useful :}. That could be changed of course - if someone wants to
write
> > code :].
>
> The cygwin installer should install cygwin packages. As for converting
> packages formats: for that you have things like the alien package, that
> works well for simple cases.
>
> It could be argued that cygwin should adopt another packages format, but
> as long as this does not happen, there's no reason for the cygwin
> installer to handle all sorts of complicated isues of packages
> conversions.
>
> I personally think that it is a shame that cygwin is reinventing the wheel
> again with the packages format, as there are a couple of mature and
> feature-rich packages formats (not only rpm: deb, bsd ports, etc.). But I
> don't know the issues here well, and I don't have the time to contribute
> code (I hardly have the time to test) so I leave this as a remark in
> private mail...
This actually gets asked fairly often - so I'm cc'ing the relevant mailing
list with my reply...
The reason we are reinventing the wheel is that the current wheels aren't
ported to win32. Porting to cygwin doesn't count, because on win32 you
cannot replace in use files - and therefore cygwin1.dll can't be used by the
packaging program itself - and neither can any related file. I.e. rpm which
needs db3, and sh can't install db3 or sh. Likewise for changing mount point
etc.
Installing the logic behind an existing mature packaging system into
setup.exe however, will prevent us from reinventing the wheel - and that is
the _general_ direction I'm interesting in coding towards. I don't know
exactly what Chris thinks - but he has mentioned avoiding new wheels as well
:}.
Rob
- Raw text -