On Sat, 21 Apr 2001, Chris Gilbert wrote:

> On Saturday 21 April 2001  2:02 pm, Frederick Bruckman wrote:
> > On Sat, 21 Apr 2001, Chris Gilbert wrote:
> > > Optional dependancies will allow the ability to have extra features
> > > turned on if you have that package installed.  Eg kdepim2 would enable
> > > kpilot if you've got misc/pilot-link installed, something that not
> > > everyone would want but some might.  It might also assist in cases of
> > > circular dependancies.
> >
> > How? Please explain.
>
> How to which part?  Perhaps I'm unusual (a freak :) in that I generally
> compile all my own packages, but I've noted that some packages don't enable
> some options which they could, eg kdepim2 doesn't enable kpilot, probably
> because the person who created that package doesn't have a palm pilot.
> However I do, and I'm sure others do, so I do want kpilot enabled, so the
> choice is do we make everyone install the pilot-link even if they don't need
> it, or allow people to build there own versions which do enable it.

What does any of what you just wrote have to do with circular
dependencies? Circular dependencies are when a package ultimately
depends on itself.

> > Having "indeterminate" binary packages would really suck. New users
> > would ask, "How come package foo gets installed on i386, but not on
> > {sparc,m68k,alpha}.  Aren't {sparc,m68k,alpha} fully supported?"
>
> As most binary packages are put up by people who've done a bulk build, it
> would make sense to have an option that disabled all optional dependancies,
> or did the complete opposite and added them to the default build list
> (however I can see cyclic dependancies creeping in there)

That's simply not true -- _most_ binary packages were not put up right
after a bulk build. And you seem to misunderstand what a cyclic
dependency is. A cyclic dependency is a bug in the package system,
which causes a package to depend on itself -- it has nothing to do
with the way a package is built.

> > As it is, it's possible to install "kde" and "gnome" from binary
> > packages only about half the time -- it depends on how conscientiously
> > the builder updated all the dependencies. This looks to me like one
> > more thing to go wrong.
>
> In which case the builder is at fault for not providing all the binary
> packages they used.  There room for human error in all that we do, this
> shouldn't make it any worse.

"True", and "false"...

> I'd expect anyone doing package builds to have
> actually removed all there existing packages so that all those that are
> needed are actually built and packaged up.

Well, it doesn't work that way. There are no dedicated tinderbox
machines doing package builds. What happens, on the slower ports
especially, is a developer updates a few packages that he uses, and
then uploads them. If you set the requirement you describe, you may as
well ban binary packages for all but i386 and alpha.

> > This could all be accomplished within the existing framework...
>
> Why should everyone have to have palm-pilot stuff installed if they've not
> got one?  Do we look like linux :)

Everyone doesn't have to do anything. If you make it a build option,
then some folks will include everything in their custom build, and
other's won't. Moreover, by having the knob in /etc/mk.conf it's easy
for the binary package builder to set the default. (Whether the
default should be "on" or "off" is a completely different question.)
If, on the other hand, you let identical appearing binary packages
have different components, depending on nothing but the machine they
were built on, you make it more difficult to get binary packages right.

> Why have it on, not everyone might want that feature.

You're missing the whole point, which is that you can make it an
explicit build-time option, without making any profound changes to the
package system itself.

There are two broad categories of users: The first-time user would be
expected to go with the binary package, and he's more likely to
complain about a feature being absent, than about one being present.
The more sophisticated user is expected to build his own packages, and
he'll know how to tweak the build-time options, at least, so he knows
what to do about "bloat". Thus the "rule" to turn everything on by
default, but there's room for discretion, of course.


Frederick