Mike Meyer wrote: > I don't see that it implies that at all. If the environment isn't a > development environment, you may want that behavior to conserve > resources, but it certainly wouldn't seem to be a requirement. If the > environment is a development environment, you almost certainly want > the development bits for everything you install in it, as otherwise > you risk tools you are building quietly breaking because a library > they use couldn't build some capability based on a missing header > file.
Are you saying that if I install Gnome Evolution to check my email, then the X11, Gnome, and dbus development bits should get installed automatically if I have Sun Studio installed? If I uninstall Sun Studio and DTrace, will the development bits be automatically removed? If I install DTrace after I install Gnome Evolution, will all the X11 and Gnome headers get installed with it? In particular, if I install DTrace, do I have to re-download all of my packages from the server in their entirety to get all their headers, or would I be able to download just the bits I don't already have? If I have some headers installed, and then install DTrace, would all my header files get updated to the newest release? No matter what, the end user experience needs to be simple, consistent, and predictable. In some cases that does imply installing optional stuff just in case the user needs it (e.g. online help). "pfexec pkg install gnome-evolution" needs to have a predictable result, whether Sun Studio or DTrace is installed or not. When a normal user (non-developer) uses Package Manager, they shouldn't see a bunch of options for installing stuff they don't understand; they should be able to double-click "Gnome Evolution" and have it installed, without ever seeing anything confusing like "header" or "devel" or the Usr/Root split. Having the development bits listed separately and installed only when explicitly requested is the most obvious way to ensure that the user experience is simple, intuitive, and predictable. Your concern is that people will build packages with missing components if the header files are missing. In the modern world, that doesn't happen. Build-time configuration and end-users users building their own custom binaries for their machines is an outdated model. People want binary packages built and tested by a professional. People want that distributor to give them instant, automated security updates for those packages. People want to use the same binary packages that other people are using (safety in numbers). They want to configure those packages at *runtime*, not at build-time or installation time. *Very few* people are building packages, and *many* people testing the ones that are getting built. "Oops, SSL support wasn't compiled in because I didn't have the headers" cannot happen in this model. First, the people building the packages would notice it right away if they were doing *any* level of quality control. Even if they did let such a release slip through, one of their testers would fine it quickly. If a user actually did encounter this problem then they should take it as a sign that they need to find a better distributor. Like you said, the people building packages should be building them in a carefully-controlled environment separate from their everyday runtime environment. That requires explicitly installing exact versions of all the development bits needed to build the software (OS, compiler, libraries, header files, build scripts, etc). I do agree with you that separate (virtual) machines make a lot of sense for keeping the build environment separate. But, automatically installing development bits that were not explicitly asked for runs counter to that. For example, installing DTrace into the development environment would effectively destroy it by mixing in tons of new headers. That is why I think that development bits should only be installed when specifically requested. DTrace is an interesting case because of its use of header files. Very few users will ever use DTrace even once. When they do use it, how important is it to have the header files? Are the header files required for use, nice to have, or rarely helpful? AFAICT, it is hard to justify having hundreds of megabytes of header files installed at all times just so DTrace can use them. On the other hand, I suppose if people were short on disk space they could just uninstall DTrace. - Brian _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
