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: A quality relationship

ioannis@flinet.com (Ioannis Tambouras)  wrote on 21.02.97 in <Pine.LNX.3.95.970221190034.9819A-100000@ohiox.haw.org>:

>   The debian packaging system also has major disadvanges. The most prominent
>   to me is lack of brief documentation. I need 10 pages that will teach me
> in   one evening how to build and upload simple packages for distribution.
> Do you   really think a software developer is willing to learn the whole
> debian   packaging system in order to add an extra "make deb" line in his
> Makefile?,   or, the admin to get a 2-year degree from debian.org in order
> to keep his   system straight? No way!

Also no real need.

Upstream dpkg support could be fairly simple.

Tell the upstream developer to first support autoconf or similar stuff.

Then, have some Debian guy create the almost-trivial debian/* files that  
will be needed for most packages, and write a brief pamphlet on where to  
change things if the package has changes (like a new doc file), and to re- 
contact us for more serious changes.

The rest is just about about automatic. We only need to fetch the source  
and do a build (and tell upstream if (s)he goofed) - just like what the  
non-intel guys do with most packages.

Remember, autoconfed sources are usually easy to package, and once you  
have packaged something, *usually*, you won't need to do much for a new  
version, and most of that is finding just what upstream changed.

Oh yes, there are policy changes. Put as much as possible into some  
central tools, and have someone submit diffs upstream for the rest.

I'm not saying that every package should be handled that way. Obviously,  
we'd want to keep stuff like init or libc with "real" debian developers,  
and however easy it gets, there will always be upstream developers that  
won't do it, for whatever reason.

I'm just saying that, for a lot of packages, it's not really that hard.  
Especially for most GNU packages.

MfG Kai


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