On Fri, 2003-06-27 at 14:16, FACORAT Fabrice wrote: > True. > On top of that we can think a little bit about rpmdrake and linux > system. With linux user can't easily install an app if the app is : > 1°/ a package that requires others libs
? That's exactly what rpmdrake is for. > 2°/ not a rpm provide by mdk ( as others rpms may not work well because > of provides/requires/etc ... pb ) This is not something we should "fix". Instead, users need to understand why it is not in fact a problem. > What about a foreign/not mdk package ? ... urpmi/gurpmi. Why ? because : No. Making it easier to install non-mdk packages is simply making it easier to screw up the system, so make it as hard as possible. > 1°/ It will try to install this package and the required dependencies if > possible. If it failed ... sorry it's linux, not windows. dependencies are not a sufficient safeguard for foreign packages, because of such things as overly fuzzy dependencies (say a Red Hat package just says it needs libxyz, because there's only one version of libxyz in Red Hat, so it installs happily on Mandrake, where there's a completely different version of libxyz, then crashes on run). > 2°/ it simple No. See above. > We try to imitate windows but it's impossible with linux. > On windows you have a file that normally have all that it need inside it > ( dll or static ) and put them in his directory or use standard windows > lib. If you miss something ( seldom ), just grab the right file, most of > the time it's just the new DirectX. > The nightmare with windows was the fact that some apps override some > windows systems dll and of course the registry ( what a mess ). But > besides that install an app was easy. Want a game ? put the CD, > setup.exe and during install process if it need new directX it provide > it for u or u can simply install it. > > On linux ? take the rpm/sh. arf need libGL.x.y-z and your sys have > libGL.x.t-u and several libs depends on it. upgrade ? sometimes some > apps requires specific version of a lib -> no way. The solution ? the > game should provide everything, put this in his own directory or in > /usr/local or in /opt . Linux libs change quickly and often break > compatibility somewhere ( API, ABI for C++, behaviour) because most of > them are not mature yet. You're simply talking about static compilation, which is exactly what commercially distributed, closed-source games for Linux do. It's really far less of a problem than it's made out to be. Quake 3 works perfectly well on Linux, for instance - it just has all the stuff it needs statically compiled into it, you drop a copy on any remotely modern distribution with sufficient hardware and it will run perfectly. > To sum up it's more freedom and openess ( Opensource, free software, ... > ) for less freedom ( use only what your distro provide you if you're a > newbies or else you will have to dig inside things more complicated ) Which is correct for now. Until it's less dangerous to install non-mdk packages, we should not make it easier to do so. Of course, it would be very nice to work towards *making* it less dangerous, but get the two in the right order. :) -- adamw
