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: Is it time to abandon Dpkg?y

On Mon, 23 Dec 1996, Chris Fearnley wrote:

> 'Ian Jackson wrote:'
> >
> >When I get time to work on dpkg the new dselect interface will be my
> >top priority, unless someone else has got there first.
> 
> I promise to have something in the way of a high-level menu before the
> end of January (In fact before Jan 20th when I leave for three weeks
> in Sunny Calcutta).
> 
> All other dselect wanabe developers:  come up with your own ideas.
> Mine may be suboptimal.  Let's not put all the eggs in Ian's or my
> basket!  And comment on the selectmenu config I posted.

Yes, I think it is confusing.  Perhaps we need a simpler
approach?  I think having a simple, fluid interface representing
"default" configuration settings is the best thing.  We would
need to make decisions on how to treat packages and package
groupings in a default way, which I think is a good thing.  The
flexability should be "buried" in a separate config menu, where
default values/behaviors can be changed.  The "installation" face
should deal with just that, while the post installation face
would be fully functional (or perhaps the installation face could
have a menu option to run in full face).

I also think we need to have somehting like "meta packages" where
things like "X" are identified by us as a set of packages related
to X that we think we should install as default packages.  We
could have things like glibc, X, Xapps, glibc-dev, X-dev, TeX,
Text, etc. which could be further grouped into installation
options like "minimal workstation", "developer", "full install",
etc. with disk space requirements calculated for each install
group.  

These are probably two separate but related issues.  In any case,
I think that the power of dselect is overshadowed by its
complexity, so we should hide the complexity.  It doesn't mean we
have to sacrifice anything, just reorganize functionality in the
interface.

Just my $.02

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