Date: Sat, 9 Sep 2000 01:27:55 -0700 (PDT) From: Kris Kennaway <kris@FreeBSD.org> To: ports@Freebsd.org Subject: Vision statement Message-ID: <Pine.BSF.4.21.0009090127060.18449-100000@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 <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.0009090127060.18449-100000>