Good idea but what about something similar to the pkgadd,pkgrm,pkginfo form
of Sun but cross platform...?
-matt chapman
-----Original Message-----
From: Gordon Messmer
To: [EMAIL PROTECTED]
Sent: 7/12/2000 2:54 AM
Subject: An idea I've been tossing around....
I've been thinking about something for the last couple of days, and I'd
like to share some of my thoughts with other users.
Please let me know what you think, and I hope this doesn't waste too
much time and bandwidth :)
MSG
I've used rpm, dpkg, FreeBSD's ports and InstallSheild for a number of
years (some more than others). I think that now is a good time to
create something better, with the best features of each and a few
ideas that are new.
The system I have in mind has a few guidelines so far:
* The system must be Free Software.
* The system should use a standard file format. rpm2cpio is a fine
example of what I do not want to do. It's a good tool, but I think
the package should be a compressed tar (or cpio) package with headers
at the end of the file. I believe that this is the way the SLP
packages are implemented. With this arrangement, no special software
is needed to use packages created by this package manager. Virtually
every UNIX like system has tar and cpio; gzip is available. Users
that don't have this package manager installed in their system can
still easily use these packages.
* To the greatest extent possible, the system should be modular. Any
features that could be handled by a driver should be. Functionality
should be built into a shared library, leaving only UI issues in
applications. Drivers for file access (one for local, one for ftp,
http, smb, maybe use gnome-vfs if available) give us the ability to
access packages stored locally or remotely. Drivers for package
access (native packages, dpkg, rpm3, rpm4) would give users the
ability to install packages for other systems, potentially making both
users and packagers happy.
* I think the biggest implementation detail is what DB file format /
library to use. rpm corrupts its databases fairly easily, which is
probably the application and not the DB library. All the same, I
don't have a wide base of experience with different DB styles.
* An application should be included that will allow advanced users to
manipulate the databases directly. The idea here being that if
someone installs an application or library from source, he should be
able to launch a program that asks him for the name of the package,
version, and files that were installed.
* Like InstallSheild, the package manager should account for
sub-packages in a single archive.
* An application should be included that can update a set of packages,
or all packages by itself, like apt-get.
* I'm also thinking about a concept like FreeBSD's ports system, but a
lot more user friendly. I imaging a GUI shell incorporating support
for this package manager. It would generate a menu like GNOME or KDE
do, or maybe like a certain other GUI shell whose version was 3.1.
Packages should contain information about their place in a hierarchy,
as well as information on what programs the package provides (path,
icon, description). The GUI shell would read the section of the
hierarchy that contains GUI, end-user applications. Any applications
provided should be added to the menu / icons displayed to the user.
The cool idea is "shadow" packages. Shadow packages aren't really
installed, they just describe a package that is available. For
instance, if you installed the basic GNOME applications from Helix
Code, shadow packages would be installed for those packages that you
didn't install. The GUI shell now contains icons for the applications
you installed, but also icons for those you didn't. (Maybe
translucent or dim to illustrate the difference). If you attempt to
launch an application that isn't installed, the shell will launch the
package manager, which will ask you if you want to download and
install that package. All the information about the location of this
package and its dependencies should be contained in the shadow package.
That's most of the ideas that I have for the project now. I haven't
named it yet. With a variety of what I think are "almost good enough"
package managers / installers available now, I don't think it needs to
be rushed. Careful planning will help avoid the shortcomings of
currently available solutions. I think that an application like this
would be a great boost for developers, users, and distributors.
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
