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?

Ian:
>Even if we adopt RPM, we can still distinguish ourselves from
>Red Hat.  We could, for example, concentrate on quality,
>stability, and security; being on the bleeding edge; high
>performance; servers instead of desktops; desktops instead of
>servers (compete with Caldera, not Red Hat); or using only GPL
>or BSD style copyrights.

Very true.  There's also the (very) open development model, and debian's
non-profit nature.

Lars:
>This sounds conclusive, though a more detailed argument would
>be nice (something for the FAQ, perhaps). Especially examples
>of situations where dpkg works better than RPM. (Ian: I'm not
>asking you do this, but it would be nice to have it, I'm sure
>you'll agree.)

I'd like to see this detailed argument before a decision is made.

I'd also like to see (brief?) discussion of what it would take to extend
rpm to do what dpkg does now.

I believe dpkg has provided fairly well for extensions, tho I have not
examined it closely.

Does rpm allow extensions of the sort that would be required to make it do
all that deb does?  That is, could red hat folks install a debian-created
rpm file, and get something that mostly works?

I believe I recall hearing that the FSF was going to start putting rules
in autoconf-generated Makefile's, to create deb files.  Are they planning
to do the same for rpm?  Why or why not?

I think if we do continue with deb, that all installation programs should
read rpm files much the same way they do deb files.  That said, is it
worth the added maintenance, to handle two formats everywhere?

How many other differences are there between linux distributions, that
could render a common packaging system... misleading?  Are there library
or executable locations that could lead to puzzlement?

If rpm were suddenly made a proprietary format (I kind of doubt it would
happen), would it be possible to make older versions of rpm proprietary at
the same time?  That is, if Red Hat did try to lock up rpm (again, not
especially likely - most linux folk would be pretty annoyed), would it
then be possible to take a slightly old rpm spec and continue with that
(kind of like what's happened with zmodem)?

At one time, I believe I heard that there were negotiations between Red
Hat and Debian to arrive at a common packaging scheme, probably by merging
rpm and deb.  Has something changed with this?

Bruce:
>Since people seem to think dselect and dpkg are worth keeping, I think someone
>has to start working on a better dselect interface now. We're definitely
>snoozing on this issue, and if we don't do something about it we're gonna lose.

I don't think it's imperative that we keep -or- that we toss deb, but I do
think that if we keep deb we must have a glossier user interface overtop
of it, soon.

Possible project: a java interpreter that does graphics thru svgalib
and/or direct graphics for herc, ega and (640x480) vga.




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