Mike Meyer wrote: > "Brian Smith" <[email protected]> wrote: > > > Mike Meyer wrote: > > 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.
On any other platform (Windows, Mac OS X, Linux), I can install any email program (MS Outlook, Mail.app, Evolution) without any effect on my builds, and without needing to install any virtual machines. I'm really surprised that anybody would work in an environment that worked differently. > The rest of your questions I can't answer because - well, it depends on > the package system. This discussion is about how the packaging system should handle the development bits. My view is that there is no good way for the packaging system to install them in any kind of automatic fashion. Since installing them on demand is very easy (as is done on all other major platforms), there's not much cost to having the user install them manually. I understand that a developer following very poor development practices building software with poor build scripts might have some problems if some header files aren't installed while others are. But, that is not the scenario to optimize for. Developers following good practices have nothing to worry about. Again, look at the other platforms and you can see that it isn't a big deal. > > No matter what, the end user experience needs to be simple, > > consistent, and predictable. > > Correct. But don't forget that developers are end users. Right, that is why I want the installation of things like Evolution, Firefox, etc. to be very simple. The installation of development bits should also be simple, but I'd rather have it always do the right thing on-demand then do the wrong thing automatically. > > 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 main problem there is that the configure script is bad and needs to be fixed to detect missing components up-front. The packaging system doesn't need to waste time attempting to work around poorly-coded build scripts. No matter what workarounds are attempted, there will always be a lot of build scripts that fail. > > 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. Frankly, I don't think this is much of a problem. A developer cannot distribute software that is broken like you describe unless he hasn't tested it. The packaging system cannot make up for bad development practices. > > 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. I am not talking about mismatched headers/libraries. What I mean is that installing DTrace shouldn't change the way my software is built; that is, the bits that are generated from the compiler/linker should be the same after I installed DTrace as they were after I installed DTrace, unless I am building something that uses DTrace's API. > 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. If (Open)Solaris doesn't support low-end configurations, it will limit the ability of people to try it out. Not every environment has plentiful disk space. I am building a website that runs on a Solaris10u4 zone in which I only have 2GB *total* writable disk space. Further /usr/* is non-writable for me because the zone is sparse. This kind of no-storage configuration is extremely common in the Linux world with Xen-based hosting. Such an environment is also likely to be a Linux-switcher's first exposure to Solaris. I also run OpenSolaris 2008.11 in VirtualBox on Windows and the experience isn't really great there either. I shouldn't need 768MB of RAM and 2GB of disk space devoted to each VM just to test some software. It is extremely tedious to try to uninstall components to get the VM into a minimized state. That is why I am building a special OpenSolaris distribution designed specifically for running in VirtualBox on Windows. It is stripped to the bare minimum and comes will come with an *optional* package for automatic CIFS file sharing (so you can edit the Solaris configuration files in the virtual machine using your Windows text editor, for example). The idea is that the user can use IPS to install the *minimum* amount of stuff that is needed in the VM. It would be very unfortunate for hundreds of megabytes of unneeded files to be automatically installed when the user installs the packages that he actually needs. - Brian _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
