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]

UPM



>> - Sysadmin can freeze files or directories to not allow the package manager
>>   to disturb what was modified and what the sysadmin does not want to be
>>   touched at all.
>
>I think the database idea Bruce ans Lars were discussing offers a
>mechanism to implement this -- independant of a package manager
>(although perfectly usable by any).

Only the package manager can guarantee that no files are overwritten when
installing packages.
 
>> - Immediate configuration of Packages. No delay for the configuration of
>>   daemons that might mean downtime (dselect).  No need for predependencies
>>   (dpkg).
>
>I'm not sure what the impact of this would be.  If I replace
>the NIS package, I need to stop ypbind and ypserv, install the
>new package and restart ypbind and ypserv.  How do you plan on
>avoiding that?  I think the difference between stopping it for a
>minute and stopping it for 10 minutes is enough to justify this
>though.  Is that what you mean here?

I would like to accomplish what you assume dpkg is doing. dpkg is NOT
restarting ypbind and ypserv immediately. After disabling NIS and
unpacking the package it happily goes on unpacking other packages and
disabling other services on your system!!!!. Only when they
are all unpacked does dpkg begin configuring and activating packages. One
interactive question and your services are disabled until you get back to
the sessions. This is very destructive behavior on dpkg's part.

>> - Configuration Scripts are separate from the installation scripts and they
>>   can be repeatedly invoked without reinstalling the package.
>
>I thought that was already the case?

I want to require installation script to not be interactive at all. All
interaction can only take place in the configuration scripts which are
invoked separetely from the installation process. The current
separation is not clean since the postinst scripts usually call the
interactive configuration. At that point (using dselect) of course other
packages are scheduled to be configured and have their services disabled.
 
>> - 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.
>
>This sounds cool.  I like the idea of using a database over flat
>files.  However, I'm nost sure all this data belongs in the
>package database.  There are tools that privide this
>functionality already and it may be more beneficial to store
>some of this data in a more abstract (generally accessable) way.

No other tool can establish which files are to be modified and which are
not.

>> - 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.
>
>uuencoding sucks. 'nuff said.

I know. But how else to gain the functionality you welcome in the next
point?

> - Screwed up package metainformation can be easily fixed up and the
>   installation scripts can be reviewed so the sysadmin is clear about the
>   dangers the scripts might pose to his system.

very good.

>> - Automatic retrieval and installation of packages a package depends on.
>
>Hopefully not so automatic that the sysadmin can't decide _not_
>to install one of these dependencies!

There will be an option to switch that off. But if you want a package then
you need the packages it depends on.

>> - Meta packages: i.e. you can have a package STANDARD that will depend on
>>   a selection of packages that are standard for a distribution and it will
>>   install those by automatic retrieval.
>I've been talking about this since last april!  There's been a
>lot of talk about this lately though.  Who will determine the
>list of standard packages?

The idea is to make the packages easily modifiable so that you can set up
your own standard package list by writing a simple meta package.

>> - Library dependencies automatically handled by package manager according to
>>   information contained in the ELF binaries or ELF libraries.  No need for
>>   error prone maintainer specification of dependencies in most cases. (rpm
>>   has similar features)
>This dhould be "automatically" handled at package build time so
>that front ends can get that information easily.

The information can easily be gotten from the binaries. No need to do
anything during build time. Dependencies to set up additional restrictions
can be manually added though (Incompatibilities with certain libraries
etc)
 
>> - Multiple Instances of UPM can use the Database simultaneously.
>>   (upm calls itself recursively to fulfill dependencies!)
>Ouch!  This counds dangerous!  How does it deal with precedences
>and conflicting modifications in concurrent runs?

By locking the package that is currently being installed of course.
During configuration it will lock all packages it depends on.
Precedences? What would be problem be?

>> - Packages with prefix ability can be installed in multiple locations.
>This can already be done with dpkg.  Unfortunately that
>information is not consulted with the next install.  I think the
>imaginary database I mentioned could handle this though.

I did not know that dpkg has that ability.

>> - Support for multiple versions of a program on a system (such as Linux
>>   Kernels or libraries for example).
>Do you mean like multiple versions of libc? and multiple versions
>of sed?

Yes. You can have libc4 and libc5 on the system and they will have the
name libc. The names libc5 and libc4 are just a fix for dpkg to get around
the inability to install multiple packages. And you will also be
able to have libc 5.0.4 5.2.7 and 5.4.17 on the same system.

>> - 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 see how this is usefule at all.

Why does the user have to choose the architecture at all? On a CD-Rom you
could simply deliver a huge package that has binaries for all supported
architectures. The package manager will select the correct binary.
Of course this is not practical for download via modem of big binaries.

--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
Please always CC me when replying to posts on mailing lists.


--
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