Re: Package management

[Chris (Ducky) Chapin]

Since it looks like RPM has been taken care of, I'll answer what I know of
dpkg and apt under debian. =)

On Fri, 19 Sep 2003 Mark.Burgess@iu.hio.no wrote:

> I would like to ask about the RPM package management stuff.
> I am not a big user of RPM, but I would like to try this
> out now and see whether it can be done for debian packages too.
> (getapt is a wonderful thing)

Dpkg is essentially Debian's version of rpm (the CLI tool and database
backend it uses). It calls dpkg-[format] to actually handle files of a
specific format, typically deb files (so it almost always just calls
dpkg-deb).

A deb is the package file format (simply an ar file) and filename
extension.

Apt (Advanced Package Tool) was designed to take care of package finding
and dependency meeting for dpkg. It's a CLI tool that GUI (both curses
and X) front-ends use. Sounds like you're already aware of apt-rpm.

> I wonder:
> 
>  How does rpm know where to look for packages?

It doesn't. Neither does dpkg. apt, on the other hand typically looks at
/etc/apt/sources.list for a list of servers to get lists of packages and
versions associated with different releases.

>  What if they are at a remote source?

This is typically the case with apt. With the rpm command, you can specify
a URL to install, but you have to already know where it is. dpkg doesn't
support URLs, only local files, so far as I know.

>  Could the packages be downloaded in from cfservd?

apt typically uses http or ftp, but can also use local file repositories,
cdrom (to handle media swapping), rsh, and ssh. Each of these methods is
handled by a file out of /usr/lib/apt/methods.

>  If so, where should they go?

I don't see why one couldn't write a handler to contact cfservd if local
file isn't sufficient. If dumping to a local repository is ok, then
anywhere is good as long as its path is in /etc/apt/sources.list

>  How are dependencies handed?

dpkg, like rpm, will tell you a dependency is not met and pretty much die
right there.

Apt first obtains a file from all its sources called Packages. It contains
all the info about all the packages in that source. Apt then merges them
into one file. This list has all the dependencies and provisions.

Packages typically state the most generic and minimum package needed to
satisfy a given dependency. ie., a package will state that it requires
"editor" rather than explicitly state that it needs "vi" or that it needs
libxml1 >= 1.8.14 rather than specifying that it needs the file
libxml.so.1.8.14. Then packages like vim can specify they provide
"editor".


As a side note, Paul Paradise (who moved on after his internship here) and
I last summer were working on a project (which eventually got shelved)
that used dpkg and apt to maintain class memberships that cfengine used to
make its configuration decisions. We would do this on all hosts and would
just piggyback on top of any Debian hosts that had dpkg and apt already
installed.


As far as future cfservd methods, I'd absolutely love a bit torrent style
of distributed file synchronization. cfservd would be coordinator (tracker
in bt lingo) and seed clients as needed. This would scale enormously as
been proven for large file distribution of quite a few products since the
availability and performace goes UP as more clients are added.

http://bitconjurer.org/BitTorrent if you're unfamiliar.

I'm interested in technologies like this because we've got more than 2200
centrally managed unix hosts that need access to roughly 100M of
configuration and binary data. They range from desktops to lab machines,
and with generic compute servers definately in the minority.

Distributed filesystems like AFS seem to be the best answer at the moment,
but sometimes AFS can't be installed since we're not the one managing that
(like an appliance or some such). This is where cfservd comes in, but it
ends up being handle as an exception method.

I'd love to go on but this emails already long enough. =) 

-Chris

--

 Christopher 'Ducky' Chapin                        ducky@qualcomm.com
 Unix Systems Administrator - Qualcomm, Inc.           (858) 651-5433
 IT Host Services - AE-209F