Date: Mon, 5 Jul 1999 23:25:39 -0700 (PDT) From: <jkoshy@FreeBSD.org> To: hutch@psfc.mit.edu Cc: ports@freebsd.org Subject: Re: TtH Description Correction Request Message-ID: <199907060625.XAA76787@freefall.freebsd.org> In-Reply-To: Your message of "Mon, 05 Jul 1999 08:58:03 -0400." <Pine.LNX.4.10.9907050834470.11014-100000@silas.psfc.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
<jkoshy@freebsd.org>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907060625.XAA76787>