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: dpkg issues

'Tom Lees wrote:'
>
>On Tue, 25 Feb 1997, Chris Fearnley wrote:
>> 'Bruce Perens wrote:'
>> >From: Christoph <debian@waterf.org>
>> >> They have been pointed out over and over and over again. There are obvious
>> >> design flaws in dpkg that are not addressed. There are issues with dselect
>> >> that are never addressed. There is a huge bug list that is not worked on.
>
>Can we release the list of bugs (automate getting it maybe?) with each
>release of dpkg? This would stop people from reporting things twice, and
>may even encourage people to work on some more trivial bugs or submit
>their own fixes (that's users, not developers).

I don't think there are any trivial bugs in dpkg.  It's subtle
software and even trivial things if poorly understood could have
disastrous consequences.

>I can't say I'll have the time to do a lot (at least until June-ish), but
>I will have enough time to do a fair amount. I think we should create a
>dpkg development group (mailing list debian-devel-dpkg).

If this gets created, put me on it, please.

>I would prefer not to work on dselect yet (not enough time), but I will
>concentrate instead on improving the current dpkg tool itself.

Feel free to skip over the UI issues in dselect.  However, dselect has
a lot of useful library-like functions that need to be pulled into
libdpkg.

>One main idea I have is to add support for brackets in dependencies, so
>you can do things like:-
>
>	Depends: (pkga, pkgb) | pkgc, pkgd
>
>Which means ((pkga and pkgb) or pkgc) and pkgd. Another idea is to add a
>line to the control field to support upgrades to the dpkg system (witness
>the recent problem with epochs and 1.2->1.3), so that if a feature has
>been added which will confuse older dpkg's, the dpkg can ignore it, and
>warn that dpkg needs to be upgraded.

Can we hold off on features until we have documented dpkg/dselect's
internals and cleaned up the code so that it's easier for non-Ian
people to work on it.

>Other things that need to be done are creating a libdpkg (I'm doing this
>now), cleaning up the source generally (I object to calling two functions
>"ohshit" and "ohshite"...not only is it confusing [what is the
>difference, etc.], but it may offend some people, and it looks
>unprofesional). Then, I'll work at updating the documentation, the stuff
>on the TODO list, etc. I've just converted the whole lot to use automake
>and libtool and gettext, and canonicalization.

Documentation, then code cleanup, then libdpkg, and only lastly new
features would be my prioritization.  In fact, if you document it, I'll
read the docs and the code to try to verify it.  We do need a team of
people who understand dpkg thoroughly.

-- 
Christopher J. Fearnley          |  Linux/Internet Consulting
cjf@netaxs.com, cjf@onit.net     |  Design Science Revolutionary
http://www.netaxs.com/~cjf       |  Explorer in Universe
ftp://ftp.netaxs.com/people/cjf  |  "Dare to be Naive" -- Bucky Fuller