On Fri, 12 Dec 2008 12:15:52 -0600 "Brian Smith" <[email protected]> wrote:
> 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 you're going to be building in that environment, then yes. Of course, I'd say putting most of those things in build environment is a sign of questionable sanity to start with, but that's just me. The rest of your questions I can't answer because - well, it depends on the package system. > No matter what, the end user experience needs to be simple, consistent, and > predictable. Correct. But don't forget that developers are end users. > 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. No, it isn't, because it fails miserably when the end user is a developer. They only that get nice experience if the development bits are there when they need them. Otherwise, they wind up having to go through a series of trial build, each one of which turns up some development bits they needed but didn't have. And that's if they're lucky. Then they get to start the same process again, this time finding development bits that caused some auto* tool to simply elide the functionality those bits were required to provide, so they get caught in testing. The only obvious way to get the end user experience you want for all end users is to include all the development bits with every package. If for some reason you're not willing to do that, you have to start looking into non-obvious ways of doing things. > 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. No, I'm concerned that people will build *software* that is missing functionality if some header files are missing. Not every software developer builds packages for a distribution, and not everyone who builds packages will actually make them available to that distribution. Yes, it should be caught in the QA chain in any case. Of course, by expecting someone in the QA chain to find the problem, you're admitting that the problem *does* happen in the modern world. > 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. If installing DTRace installs headers for packages that don't match the libraries already installed, then your package system is broken. I'd say your package system was broken if it even let you install header files that don't match the corresponding libraries in the install environment. > 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. I, on the other hand, consider something as trivial as a few hundred megabytes of disk space (let's see - today's newegg special was a 500GB disk for $50, so that's .01 cents/MB, so that's a few pennies worth of storage; it might almost be noticeable if I installed it on my cell phone) to be absolutely worth it if it saves me a single build cycle over the course of a project. If it really bothers you, have your installation package create file systems for the include directories if they don't exist, and turn on compression on those file systems. <mike -- Mike Meyer <[email protected]> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
