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: Go with UPM, or fix these problems with dpkg/dselect?

On Thu, 16 Jan 1997, Bruce Perens wrote:

> I think the internal format of dpkg and its databases are not as
> important as this problem list:
> 
> 	Problem: Installation fails because of dependencies not met,
> 	batch installation of workgroups not possible, interactive
> 	configuration is spread over too much time, packages are not
> 	configured immediately.
> 
> 	Solution:
> 		Implement selection-time configuration for dpkg
> 			Requires a simple database
                    
I'm not so sure this should be too simple a database.  I think
that each package will have some configuration data required --
parameters.  These parameters will have a list of possible
values, and these values could exist in one or more states (i.e.
default selection, least dseireable, active selection, etc.).
That's just for beginners.  It could easily get more complex from
there.  

There could easily be system wide parameters shared by
packages.  These would need to have more states available to 
their possible values to allow other packages to make correct
non-interactive decisions on whether to use the system wide value
or override it.  There would also need to be other "things"
involved such as state information considerations.  I.e. the
database should save state information based on a handful of
criteria: one or more user defined real time states (e.g.
weekly), states between program runs (which may just mean between
access times of a region), and possibly others.  Network-centric
tools could be created to manage such a database, and it would 
need to deal with a session terminating prematurely, etc.  

If maintaining a unix system were simple, everybody'd be doin' it ;-)

On the other hand, anything 'll do just to get the mechanism in
place :-) 

Thanks

Richard G. Roberto
richr@bear.com
011-81-3-3437-7967 - Tokyo, Japan


--
*******************************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, offer or
agreement or any information about any transaction, customer account or account
activity contained in this communication.
*******************************************************************************


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