On Wed, 3 Jul 2002, at 12:20pm, Derek D. Martin wrote: > Missing from both right now, I think, is the ability to say that a > particular package is recommended, but not required (does dpkg do this?)
Debian's system does do this. A package can be "Required", "Recommended", or "Suggested". It is very nice in this regard. > IOW if I want gnome but don't have a sound card, then esound isn't going > to do me a damn bit of good... The problem here is that, because GNOME is a big, interconnected environment, any GNOME application (e.g., gnome-terminal) ends up being linked to the libesd library. You might be able to disable it at compile time, but you would have to recompile the world to do it. The best solution available is to install the esound package and disable the sound daemon itself. > This is a quite impressive feat, and Red Hat would do well to copy it. I actually think Red Hat would do very poorly to copy it. The main reason Debian can only get a release out every three years is the size of the package repository. A rule of configuration management is that the complexity of the system is roughly equal to 2 raised to N, where N is the number of components in the system. Debian has, what, 3000 packages now? So, the number of potential interactions is 2 to the 3000th power. That yields a number about 900 digits long. I expect Debian will eventually have to split the repository into several smaller "mini-distributions", managed independently of each other. That way, you could, for example, have a stable release of the "base" system, at which point (1) "base" maintainers can start working on the next release and (2) other maintainers could start developing against the new "base" release. As things stand right now, all 3000 plus packages have to be in sync for a release. That is insane. > The problem is worse when you consider all the other vendors who use > RPM... often RPMs for one system won't work on another (though often they > will). That is not a problem with package managers. It is a problem with computers in general. I've said it before and I will say it again: Binary packages are very dependent on their build environment. Just because RPM is smart enough to *tell you* this does not mean the problem is with RPM. > Packages built for distros that use it as their core will work on all of > the other distros that use it too... Unless there is only going to be one release of UnitedLinux, and they are never going to ever release any updates, that will not be true. For what happens when you have release 1 of the C library from UnitedLinux, but I built my package against the updated release 2? What *would* help, and is not done nearly enough, is if software designers and package maintainers put more effort into making sure different versions of their libraries could co-exist on the same system. Don't get me wrong, I think things like the LSB and UnitedLinux are a good idea, but they are not a panacea. -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
