From: John P. <jo...@cu...> - 2007-03-23 00:49:34
|
Hi again, Keith Marshall wrote: > On Thursday 22 March 2007 17:32, Gianluca Sforna wrote: > >> On 3/22/07, Keith MARSHALL <kei...@to...> wrote: >> >>> John Pye wrote: >>> >>> Have you ever used RPM? Have you not heard of `RPM dependency >>> hell'? >>> >> These days there are a bunch of depsolvers out there which allows not >> one, but many RPM based distros to survive in that hell. >> > > And, AFAIK they are all hosted on GNU/Linux. Perhaps you know > otherwise, but I don't think RPM fits well in the Win32 world. Even in > the GNU/Linux world, RPM is painful; please believe me -- I've used > RPM, and it ain't a lot of fun. > I'd like to know why you think that about RPM in the Win32 world. AFAICT the RPM database would have to live *inside* a *single* entry in the Windows 'add/remove' programs menu; the user could uninstall all of MinGW en masse, or else could chose to use the package manage to add and remove specific MinGW components (rather similar to the way MS Office deals with things) The point with RPM is that you put something like apt-get or yum on top of it and it becomes very easy. > >> Please also consider we are talking about projects orders of >> magnitude more complex than mingw/msys, that is, thousands of >> packages compared to a (few?) dozen >> > > Sure. RPM is a sophisticated package manager; way beyond our > requirements. The real killer is that it's pretty much a Linux only > solution. > Why is it beyond our requirements? If we had it, then adding new tools to the MinGW repository /could/ be as easy as rebuilding a .src.rpm on Linux and uploading the binary to a repository! We would be opening the way to centralised management of applications like XMing, GTK, Inkscape and so many more. World domination! Lay the right foundation and so many things would be easier in the world of FOSS on Windows. You say that it's pretty much a linux-only solution. I'd like to know why you think that. Perhaps there are some insurmountable low-level issues that I don't know about? > >> Anyway, I noted in your other reply that the (current?) installer has >> dependency tracking capabilities. >> > > Perhaps not at the moment; my hope is that, as we add capabilities to > install optional extra packages, we can incorporate the intelligence to > realise that when the user selects, e.g. autoconf, that perl must also > be installed. > I think that there is a *lot* of functionality behind that statement, and that that is one of the reasons for going with an already-established toolchain. For example what if too installed packages require different versions of a library but that library doesn't permit both to be present. In other words resolving conflicts. The other big thing is doing big system updates when a lot of dependencies change all at once. > >> If that is true, I'm not going to >> waste more time on that, since that was exactly why I though about >> using rpm into msys for installation purposes. >> >> BTW. Which OS are you using? >> > > In my office, Win2K (reluctantly, out of corporate necessity). On my > desktop box at home, OpenSUSE 10.0 (RPM). On my laptop, Ubuntu 6.06 > (DEB). I've run various RPM based distros, since Red Hat 6.2. FWIW, > I've always found it much more convenient to eschew the package > manager, in favour of installation from source tarballs; I'm not much > impressed by either RPM or DEB capabilities. I think you might be a bit at odds with a lot of 'regular users' in that view. Most of us really appreciate being able to fall back on a well-defined set of binaries that have been built and tested and released. When we go down the route of producing our own binaries for tarballs, we're heading in the direction of unreproducable fiddling. I am gradually coming to the view that Debian packages may be superior to RPM (eg with their 'suggests' dependencies) but I still haven't worked out how to package debs. It seems like a slightly steeper learning curve, perhaps. If RPM and DEB don't impress you, then why aren't you using BSD? JP |