From owner-freebsd-ports Sat Sep 9 1:28:58 2000 Delivered-To: freebsd-ports@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 7358837B422 for ; Sat, 9 Sep 2000 01:28:54 -0700 (PDT) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id BAA32213 for ; Sat, 9 Sep 2000 01:27:55 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sat, 9 Sep 2000 01:27:55 -0700 (PDT) From: Kris Kennaway To: ports@Freebsd.org Subject: Vision statement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Since Steve has been asking for it.. ---- The FreeBSD ports collection is divided into two areas: the ports collection itself, and the package collection which is derived from it. The ports collection contains tools for building packages and for developer assistance in creating them, but apart from that the two should provide the same set of services to the end user. In particular, there should be no functional differences relating to the installed software and what can be done with it, whether it was installed from the port or the package collections - they should be viewed as different interfaces or paths to the same end product. Both should provide equivalent tools for examining and manipulating installed software, and should be interoperable. In practice, this is implemented by having the ports collection use the package tools to manipulate installed software, and by duplicating the information and tools available within the ports collection framework in the package format and tools. As a result, users who wish to compile the software themselves and/or customize its behaviour arbitrarily can use the ports collection interface, but those who do not wish to can install an equivalent package with no significant loss of functionality. Users should not in general be forced to use one interface or the other. In particular, this means that for ports which have multiple compile-time options, multiple packages should be built from the same port. However for some complex ports with many options this may prove impractical and only the most popular combinations built. Henceforth the term "ports collection" will refer to functionality provided by both ports and packages unless otherwise indicated, and "package" to the software and associated metadata which both collections install. The ports collection should maintain an accurate representation of the dependencies which exist between various installed packages. It should not impose any additional restrictions on co-existence of installed packages beyond those which are intrinsic to the contents of the package. There are two types of dependency which a piece of software may have: those which are required for building or operation, and those which provide additional or enhanced features if present, but are not required. The ports collection should handle both types transparently. "Soft" or "passive" dependencies (those of the latter type) should be detected by the port framework (e.g. by encoding a list of all of the software which the software build framework will detect and/or can make use of), and a dependency registered if the appropriate package is found to be installed on the system - but it should not be installed if it is not present. The port may allow the user to convert a soft dependency into a "hard", or "active" one, by providing a switch to the user which will force the installation of the dependant package if it is not found. The port may also allow the user to disable the detection of a soft dependency by forcibly preventing the software from detecting it if it is present. The port may provide switches for enabling or disabling features which do not depend on other software. These switches should also be used during the creation of packages to provide a (preferably full) range of feature options with dependencies on the appropriate parent packages. Most soft dependencies are a property of the build mechanism, i.e. they change the way in which the software is built, so they are not appropriate for packages - but there may be some packages which can adapt at runtime to the presence of other software. However, by definition this software can run with or without the other package, so there is no need to register a dependency in the package. Therefore, soft dependencies are not required in the package system. Dependencies should be flexible enough that they do not constrain or provide a false view of the actual dependencies between the installed software. In particular, if a child package can operate with a range of versions of a parent the dependency check should recognise and allow this. This means that child packages must be able to specify a range of acceptable versions for their parent package. In practice the package will usually accept all versions of the parent, unless specific incompatibilities force it to only allow certain versions or a certain minimum version. Similarly, packages must be able to specify other packages which they conflict with, so that the user does not damage his system by installing two packages which do not work together and may have unexpected consequences. A list of available packages should be maintained including dependency and conflict information (the current ports INDEX file would suffice, except it would need to be updated with each version update of a port). This list could be maintained online or provided as a local file. This list provides sufficient information to allow upgrading of installed packages without breaking any components in the dependency tree: the new package contains information about whether it can be installed with the existing versions of parent packages, and can fail if not (or optionally trigger an upgrade of the out of date parents). Likewise, the external index contains up-to-date information about whether new versions of child packages are available, and if not whether the current version is compatible with the new package. If any child ports are not listed as compatible with the new version of the target port, the operation will fail or can trigger an upgrade of the out of date children. Note that it is not practical to determine whether an out of date child package (i.e. one for which a newer version exists) is still compatible with the new version of the target package, because that would require updating the version compatability information for every version of the child package over its entire history. -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message