From owner-freebsd-ports Mon Jul 5 23:25:41 1999 Delivered-To: freebsd-ports@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 1305914C0C; Mon, 5 Jul 1999 23:25:39 -0700 (PDT) (envelope-from jkoshy@FreeBSD.org) Received: (from jkoshy@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id XAA76787; Mon, 5 Jul 1999 23:25:39 -0700 (PDT) (envelope-from jkoshy@FreeBSD.org) Date: Mon, 5 Jul 1999 23:25:39 -0700 (PDT) From: Message-Id: <199907060625.XAA76787@freefall.freebsd.org> X-Mailer: exmh version 2.0.2 2/24/98 To: hutch@psfc.mit.edu Cc: ports@freebsd.org Subject: Re: TtH Description Correction Request In-Reply-To: Your message of "Mon, 05 Jul 1999 08:58:03 -0400." Mime-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I agree that the problem is basically with your package system. Although I > can't for the life of me see why XFree should be needed to run netpbm. > Still, if you say it does ... > > One thing I can't see with your dependency system is where it can stop. Yes, handling dependencies is sticky: Consider: A) you have two ports, `X' and `Y' both of which have a dependency on a third port `Z'. We currently track only against the name of the port, and not the full set of compile time options and features that `Z' offers. Now ports `X' and `Y' could require different features from `Z', so if you adopt a minimalist strategy when creating binaries, the `Z' binary that is sufficient for `X', may not be enough for `Y'. Going the "all bells and whistles" way (which we currently do) is "safer", but adds unnecessary bloat. B) Dependencies are not static. A pseudo-real-life example: Let us say a user installs `python' from ports/lang/python and selects a certain set of modules and library wrappers at installation time. If she later wishes to install Zope (python based web software), then she could discover that her Python installation needed some specific modules enabled that are not enabled by default. Uninstalling, recompiling and reinstalling python now becomes necessary. Such changes may be needed at different levels; in some cases we could get by recompiling the dependent application with bigger table sizes (eg:- jadetex requires a `bigger' TeX). Sometimes we may need to bring in a whole new port as a sub-dependency. The current mechanism doesn't really attempt to deal with all this complexity. The underlying assumption is that packages are built as a convenience and that if you want to change things you have to fire up a make and do necessary magic yourself. This isn't very newbie friendly, I agree. Perhaps, as FreeBSD's user base grows, we will need to come up with a system that tracks fine-grain dependencies and which has the ability to recompile custom versions of dependent software `behind the scenes'. This could very well complement the current 'easy to install' package system. > Shouldn't you also include the shell, bash for example. Why doesn't that > get listed, together with the rest of the operating system that is needed Well, the facilities of the 'base system' are assumed already present, though the exact contents of the 'base system' varies a bit between major FreeBSD releases. > The other comment I have is that you might consider having two categories: > 1. Required. 2. Taken advantage of if present. I admit that distinguishing > these might be a subjective call, but I suspect no more so than the sorts > of choices I indicate above. Agreed, but as described above the situation really needs dynamic dependency tracking one and you can really only go so far and no further using the 'standard precompiled' binary route. I hope the situation wrt TtH is clarified ... Regards, Koshy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message