The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The Unified Package Manager


Just some comments...

On Sat, 11 Jan 1997 08:44:35 PST Christoph Lameter 
(clameter@waterf.org) wrote:

> - Multiple options on how configuration files can be updated. Can generate
>   diffs to prior config files and then apply modifications to configuration
>   files of prior releases to the ones provided with the current package
>   (within limits of course). Can also update keyed files (like passwd,
>   group, services) in an intelligent way. Methods can be defined for new
>   ways of automatically upgrading configuration files.

IMHO, this should be optionnal, and this should be rewievable by the 
installer. I'm very uneasy about wild automated diff/patch stuff...

> - Immediate configuration of Packages. No delay for the configuration of
>   daemons that might mean downtime (dselect).  No need for predependencies
>   (dpkg).

Then you'll have to find out the right order to install the packages, 
and this will make circular dependencies prohibited.

> - A copy of provided Configfiles is saved in a special UPM directory for easy
>   reference and restoration of the default configuration.  (In case the
>   package was messed up)

Good idea.

> - Configuration Scripts are separate from the installation scripts and they
>   can be repeatedly invoked without reinstalling the package.

That's already the case for most of the important packages 
(/usr/sbin/install-*).

> - Verification and accounting for modifications and the presence of each
>   file on the system.  For each file a checksum is stored in the package
>   managers database to allow for the detection of modifications and viruses. 
>   The package manager can list all files not managed by the packaging system
>   and can be used by the sysadmin to easily group and control
>   non-distribution files on a system.

You want to integrate tripwire functionality into UPM. Nice.

> - The package format is ascii (embedded uuencode binaries) and the package
>   can be edited or written entirely with an editor.  There is no need for
>   complicated package build commands. The package can simply be written with
>   an editor and uuencoded binaries / tarfiles can be attached to that file.
>   No rule file to maintain. In contrast to rpm the recipie is also the final
>   package making for an ease of use unsurpassable.

Surely. Making it larger too. UUencoded files are 

> - A package can be signed by PGP and transmitted via e-mail without a problem.

This can already be done with some intelligent mailers (exmh).

> - An e-mail message with a couple of packages can be fed directly into the
>   package manager for installation.

This is a simple script plus a mime.type.

> - Packages are executable. Just type the name or click on the
>   file from a filemanager and the package installs. No need to bother with
>   complicated package manager interfaces.

Is this useful ?

> - Automatic retrieval and installation of packages a package depends on.

Dftp handles this...

> - FAST operation through the Berkeley DB libraries with advanced hashing,
>   btree techniques.  Text files are not consulted for metainformation (like
>   dpkg does).

This would be a great enhancement over dpkg...

> - Multiple Instances of UPM can use the Database simultaneously.
>   (upm calls itself recursively to fulfill dependencies!)

You'll have to be an expert locker to do it right...

> - Packages with prefix ability can be installed in multiple locations.

Unuseful ? Will complicate maintenance.

> - Multi-Architecture support in one UPM package. The package can list
>   what binaries would fit what architecture and the upm manager will
>   install the correct parts on installation. (Of course it can also
>   be in separate packages if the size of those binaries is big).

I don't want to ftp binaries for any architecture in every package...

General comments: Christoph, there's a lot a good things in there.I really dislike some of them. Some others have been discussed for a long time in the mailing lists (meta-packages), maybe we could start by implementing these.
How would you handle compatibility with the existing system ?

Phil.



--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com