On Fri, 12 Dec 2008 21:32:36 -0600
"Brian Smith" <[email protected]> wrote:
> 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.
I don't do Windows, so can't comment on it. Mac OS X you're right
about, but you either have no development bits (i.e. - no XCode) or
all the development bits. The third party package systems I use on it
all install all the development bits for packages. But you're wrong
about Linux (it's my experiences with Linux that's causing me to
object to this proposal) - it's one of the systems that causes the
problems I'm talking about. The problem won't be the mail reader per
se; it'll be the software components it depends on. If it's completely
self-contained (typical on both Windows and Mac), it won't cause any
problems. If it has dependencies on other components - which is
typical for Linux and other more traditional Unix-like systemsa and
sure looks like what Solaris is doing, it can cause problems.
> > 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.
The problem is that those "poor build scripts" are the ones provided
by the authors of the software in question. If you're proposing that
the packaging system both provides build scripts that are well-behaved
*and* provides all software of interest to developers in a timely
fashion, then all you've done is reduced the cycle to build failures,
which is a major step forward. You'll also be providing a repository
unlike any ever seen before.
> > > 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.
If only everyone agreed on what "the right thing" was.
> > > 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.
Wait, I thought you were proposing that the packaging system was
*going* to fix the build scripts for all the software it included so
they weren't poorly coded! Now you're saying it'll just ignore that
software? If it's not going to install it, what are you going to
replace - well, half the software in 2008.11 - with? If it is, then
what does ignore mean? Or do you really mean ignore the pain the build
scripts provided by the packaging software is causing?
> > > 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.
The problem is that what's broken may not be functionality that's used
by the developers application. The other part is that systems with
such smart build scripts typically have test scripts that don't count
"I didn't build XXX" as a failure. The result is that you can run the
test scripts for all the components without failures, then run the
tests scripts for your software without failures, and *still* miss
that you've got components with major functionality missing. Which
result in customers coming back with "Why is your bundled version of
XXXX missing YYYY? I need it!"
But you are right - the packaging system can't fix this. All the
packaging system can do is make life miserable - or not. I'm arguing
for the latter.
> > > 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.
And that would happen doing things my way as well as doing things
yours.
> > 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.
>From watching the ON lists, the switchers first experience is 2008.x -
more accurately it failing to boot for lack of memory. And even in
what you describe as a relatively sparse environment, a few hundred
megabytes is still only 10% of the space available, a small price to
pay for saving hours and days of development time.
> 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.
Which is a much better solution that making life miserable for users
of the standard distribution.
Maybe this is a terminology problem. You're saying "provide the
headers only on demand"; I'm saying "provide them all the time if it's
a development system". I'm not asking that the packaging system
automatically figure out that a system is a development system. I'd
be happy with a well-documented user-settable knob that says "this is
a development system" that 1) caused all the appropriate development
bits for already-installed software to be installed, and 2) installed
the developer bits for new software as it's installed. If you want to
uninstall the development bits if it gets turned off, that's fine. I
believe that qualifies as "on demand".
<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
