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

-----BEGIN PGP SIGNED MESSAGE-----

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

> >> Instead of working on the issues Ian attacks those trying to offer
> >> solutions
> >
> >I'm afraid I have to agree with these points. It's been obvious for a while
> >that dpkg is the biggest problem with Debian. I sincerely believe we should
> >have given up the fight and made the switch to RPM a while ago. I think it's
> >time to do so now.

As many others have said, vice versa is also true (although I don't know
that much about RPM). People like me, who have no experience of RPM, don't
really care which is technically better... dpkg is certainly good enough,
and it works (from what I've heard of RPMs problems, we are experiencing
what they did with the one upgrade vs our epoch problem).

> dpkg has fundamental design advantages over rpm.  Amidst Ian's C++
> obfuscated code there are many brilliant ideas.  But we need an active
> maintainer(s) for dpkg.  The last time you brought this up I outlined

Maybe we ought to set the maintainer field to
"debian-devel@lists.debian.org" or debian-devel-dpkg if we create that...
The BoD could appoint a specific person to coordinate things, if we get
enough volunteers to do active maintenance.

> the sundry shortcomings of rpm.  I'd rather work on solutions than
> rehash that material.  I hope we can find someone with the ability to
> bring dpkg up-to-date.  I was encouraged by Stuart's post the other
> day.  I look forward to reviewing the work of someone who takes the
> plunge into dpkg's intricacies.  If I knew C++ better, I might even
> try it myself.

I know C++ well enough to not like it :) Seriously though, the main
problem with C++ is that it's syntax is fairly obstructive of good
formatting style, making it unreadable. I haven't studied dselect's
sources in any detail, but I could do.

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

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

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.

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.

- -- 
Tom Lees <tom@lpsg.demon.co.uk>			http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E  B8 A2 17 9D 4F 9B 89 D6
finger tom@master.debian.org for full public key (also available on keyservers)

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBMx8pl/152HGH1NBlAQFLjwP/S4CwHrp4QxvKbXIPJcDAFmb8s6ZcxgOj
KXbYYyq9RucwEMlecHdsMl2GTqyJWcaLfdUVMmLmHlAYiQED/nKkwR/RXwv3Tvcq
wQYA7PVn+KHqbx6XF9qKZfT31fa7JIFxu7ppG2hU83dLdxLWqB2gfn7Ri0Ef6eC/
fsKwnDXcRZE=
=Rma4
-----END PGP SIGNATURE-----