Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Jul 2002 16:46:31 +0100 (BST)
From:      Mark Valentine <mark@thuvia.demon.co.uk>
To:        des@ofug.org (Dag-Erling Smorgrav), Wes Peters <wes@softweyr.com>
Cc:        Dan Moschuk <dan@freebsd.org>, arch@freebsd.org
Subject:   Re: Package system flaws?
Message-ID:  <200207071546.g67FkVIL018923@dotar.thuvia.org>
In-Reply-To: Dag-Erling Smorgrav's message of Jul  7, 10:14am

next in thread | raw e-mail | index | archive | help
> From: des@ofug.org (Dag-Erling Smorgrav)
> Date: Sun 7 Jul, 2002
> Subject: Re: Package system flaws?

> One thing we could improve a lot is the package file format.  We
> currently use gzipped tarballs, which have to be completely unpacked
> before processing can begin.  One improvement we can make is to use an
> archive format such as zip that allows us to extract individual files
> quickly, so we can extract the metadata and check dependencies
> etc. without unpacking the entire package.

My idea for this is to use a hybrid format.

The package itself would be an uncompressed archive in any available
simple format.  Non-sequential access to the members of the archive
is non-critical for local storage where seeks are "cheap" (so tar
archives would be acceptable for that purpose, or for when the
entire archive will be transferred, e.g. from an ftp server), but
compressing the entire archive would be a significant efficiency loss
due to having to uncompress before seeking.

For package installs over slow data streams, however, sequential access
to the archive is important.

A _directory_ makes a good direct-access archive (whether stored locally
or via ftp/web/whatever server).  If that's unpalatable, then a server-
side CGI/PHP script could serve up member elements from a sequential-
access archive.  In any case the tools should accept a directory name as
a package archive.

However, the archive members are _not_ the individual files comprising
the package.  Instead, the package is split into logical sub-packages
(there may be only one, that's fine), such as the core run-time package,
language sets, development headers and libraries, end-user documentation.
Each sub-package is stored as a compressed archive (.tar.bz2 or whatever).
The _package_ archive comprises the package metadata files (optionally
compressed - useful for the larger files such as +CONTENTS) and the
sub-package(s), each as a package archive member.

The idea here is to allow individual access to those parts of the package
that are needed individually, whilst gaining the benefits of compressing
major portions of the package as collections of files (to which individual
access is not generally required).

While the division of an existing port into sub-packages requires effort,
it's necessary only to gain the benefits of optionally-installable sub-
packages.

For existing ports, and for the majority of ports which will never likely be
sub-package, pkg_create simple creates the package archive using the existing
metadata files and a single compressed archive of the packages files.

Examples 1: simple package, not sub-packaged.

    $ ls /var/spool/pkg/foo-x.y
    +COMMENT        +DESC           +INSTALL
    +CONTENTS       +DISPLAY        base.tgz

Example 2: package with optional development and documentation components

    $ ls /var/spool/pkg/bar-m.n
    +COMMENT        +DESC           +INSTALL        devel.tgz
    +CONTENTS       +DISPLAY        base.tgz        doc.tgz

The package install tools would allow the user to select between optional
sub-packages.  The base sub-package may be marked as "required".  If there
are only "required" sub-packages, or the user elects to install "all" or
"only required" sub-packages, no dialog is necessary.  And so on..

		Cheers,

		Mark.

-- 
Mark Valentine, Thuvia Labs <mark@thuvia.co.uk>       <http://www.thuvia.co.uk>;
"Tigers will do ANYTHING for a tuna fish sandwich."       Mark Valentine uses
"We're kind of stupid that way."   *munch* *munch*        and endorses FreeBSD
  -- <http://www.calvinandhobbes.com>;                  <http://www.freebsd.org>;

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207071546.g67FkVIL018923>