Subject: Re: dependencies database
To: None <tech-pkg@netbsd.org>
From: Jeremy C. Reed <reed@reedmedia.net>
List: tech-pkg
Date: 09/20/2002 10:06:37
On Fri, 20 Sep 2002, Frederick Bruckman wrote:
> That does sound like a good idea. The tool really needs to run on the
> server, so it can read the dependencies out of the packages without
> downloading them (a cgi program)?
Yes, the tool would be run on the server and that server would contain
that master list (or database).
I think a CGI would be nice additionally. But also a single master
database (containing dependency and other info) could be generated
or updated after new packages are made (or uploaded) to the package
download server. See my comments father below about this.
> What would be neat, too, is if there were a tool that could pick out a
> complete, nearly current set for 1.6-common from the 1.6, 1.6.1, (and
> so on...), directories. That way, you could at least burn a CD that
> didn't contain dozens of obsolete packages for every current one.
Can you share an example (so I can understand this better)?
On 20 Sep 2002, Nathan J. Williams wrote:
> Debain tools use this file to resolve dependancies and figure out what
> and where to download things, as well as to present possible packages
> to the user.
In fact, I was thinking of exactly that use. To clarify it for
non-Debian users (simplified):
- When using Debian's apt-get tool you can do an "update" to download
these Packages.gz files so "so that information about new and updated
packages is available".
- It can be customized to download multiple, Packages.gz files from
different download sites (for example, just security updates, or leading
edge software, or your own customized packages, etc.)
- Then you can use the apt-get tool to do an "upgrade" which first reads
these package list(s) and builds a dependency tree, then compares your
current packages with those available and then fetches any packages that
have newer versions. Then it upgrades to them. It will not install
packages that are not currently installed.
- An "apt-get dist-upgrade" is like the previous "upgrade", but it will
handle changing dependencies as needed (since the "apt-get upgrade" won't
install different packages).
- You can also easily install one program and required dependencies with
"apt-get update" (to update your database of available software) and then
"apt-get install name-of-package-without-any-version-numbers-needed".
- apt-get keeps all the downloaded package files saved. (Old package files
can be manually or automatically removed.)
- other tools allow quickly searching/seeing what packages are available
This could all be done by providing:
- a simple database of the available packages;
- an writing some wrappers around ftp and pkg_add (and pkg_info).
(This is different than the current method of fetching one binary,
get dependency information from it, and then continue on, which may or may
not be available or work.)
Here is an example:
Package: abiword
Priority: optional
Section: editors
Installed-Size: 5127
Maintainer: Darren Benham <gecko@debian.org>
Architecture: i386
Version: 0.7.7-1
Depends: libpng2 (>=1.0.5), libc6 (>= 2.1), libglib1.2 (>= 1.2.0),
libgtk1.2 (>= 1.2.6-1), libpng2, libstdc++2.10, libz1, xlib6g (>= 3.3.5)
Recommends: ispell-dictionary
Conflicts: abi-fonts,abisuite
Filename: dists/potato/main/binary-i386/editors/abiword_0.7.7-1.deb
Size: 2470490
MD5sum: 060f6a5af56fbe028ecb39218aa61254
Description: WYSIWYG word processor based on GTK.
AbiWord is the first of a complete, open source office suite. AbiWord is
based on GTK and the original source includes crossplatform support for
win32 and BeOS.
.
AbiWord is still being developed. It's quite usable but not yet full-
featured or polished. For many applications, however, it should prove
effective and efficient.
.
This is a 90% upstream produced deb
A few other fields are available too (for example, a field to could be
used by the recently proposed SUGGESTS).
The Priority is used for semi-intelligently knowing what is needed, like:
required (necessary for functioning system), important (common Unix
software for bare system), standard (like Emacs, parts of Tex), optional
(like X11), and extra (may conflict with other packages),
Thanks for the reminder Nathan.
To paraphrase all this: a simple database of available, downloadable
packages with dependency information could be useful for quickly
-- and reliably -- installing software.
Jeremy C. Reed
http://bsd.reedmedia.net/