Date: Fri, 8 Sep 2000 19:08:32 -0700 (PDT) From: Kris Kennaway <kris@FreeBSD.org> To: Satoshi - Ports Wraith - Asami <asami@FreeBSD.org> Cc: Will Andrews <will@physics.purdue.edu>, FreeBSD Ports <ports@FreeBSD.org> Subject: Re: Ports Options Paper Message-ID: <Pine.BSF.4.21.0009081902480.86583-100000@freefall.freebsd.org> In-Reply-To: <vqcwvgm72mi.fsf@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8 Sep 2000, Satoshi - Ports Wraith - Asami wrote:
> * The package should carry information about which versions of its parent
> * dependencies it works with - if they conflict, they must be upgraded too.
> * This has been implemented by NetBSD already.
>
> Let's take it from them then.
Good idea :-) Unfortunately it make take a bit of work since it probably
has other infrastructural baggage which needs to be ported.
> * Upgrading children is more difficult since a package generally wont know
> * what packages may depend on it, and until you fetch any new versions of
>
> What's wrong with using +REQUIRED_BY? That will give you the list of
> ports that depend on it currently. (Of course, a new version may or
> may not depend on it anymore, but it won't hurt to upgrade it anyway.)
I meant that the new version of the package can't carry information about
all possible children and which versions are compatible with it. An
installed package knows which installed packages depend on it, but not
whether they will work with the new version.
> * the children you wont know if they can co-exist with the parent and don't
> * need to be upgraded after all. Upgrading all children would be a
> * reasonable improvement over what we have now, and the ports index could be
> * used to infer the missing data if it's present (i.e. the ports index
> * carries the same information which would be obtained by fetching the
> * individual package and checking for a version conflict, so you can just
> * use that if it's up to date)
>
> Does the NetBSD index contain information on necessary version ranges
> for dependencies too? If so, yes, that should work.
I'm not sure - someone should look into it. Any takers?
> No, I'm saying this is a solved problem. The MASTERDIR method works
> well enough, I don't see why we need to change it. Having one
> directory per port is extremely useful for parallel package building.
>
> As Neil proposed, we can even hide the extra Makefiles in
> subdirectories when we go multi-level. At any rate, this has nothing
> to do with how Will proposes to implement options (which I think is a
> good idea), so I suggest we drop it and concentrate on the main
> issues.
OK. The extra files required concerns me a bit (especially since some
ports contain several options which there might be demand for in various
combinations), but I'd much rather just have the ability to do it somehow.
If you're happy for maintainers to just create additional child ports
which set the relevant build option, then that's fine by me. We can always
come back to it later.
Kris
--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <forsythe@alum.mit.edu>
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?Pine.BSF.4.21.0009081902480.86583-100000>