> Because as everyone knows the last 10% takes 90% of the work and often ends up > hurting the other 90%.
Then it's being done wrong. > The point is Debian needs to work for as many people as possible. We are > doing Yes, that's exactly the point. > apt-get source qpopper [...] > dpkg -i qpopper-<version>.deb > That is about all you need do. To be fancy, you could "fix" the postinst and > what not to not have the two stomp on each other. What's so hard about wget ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper2.53.tar.Z tar zxvf qpopper2.53.tar.Z cd qpopper-2.53 ./configure --options make su make install > The point is if you are claiming to know enough to test devel code, experiment > with server configs and the like, but are not willing or know enough to > compile a few apps, then maybe you are in the wrong line of work. That's ridiculous. What you're implying is that Debian is for people that don't know how to compile their own software. It's not. If anything, mucking about with debian/control is more work than getting the pristine source and installing into /usr/local. Why even bother with packages then? Why do we waste valuable disk space on master by compiling for other architectures when they can quite easily do apt-get -b source? I mean, the majority of Debian users have to be i386ers. Why waste all that work providing a binary distribution for m68k? Most Debian users are never going to have any use for a m68k .deb. And Debian SPARC? Please. Why should we waste our time when Solaris works just fine? And Alpha? Those people are always sending in patches complaining about 64-bit compilation problems. It just complicates things for everybody. There can't be that many people using Alpha. Obviously they can patch their own sources and not bother us with fixing the upstream. Why should we? I'll tell you why. Because if it won't compile on that arch, it's BROKEN. Just like having POP servers conflict is BROKEN. > And by first point still stands, what you want runs against what most people > would call a "production" server. I would never run an untested daemon on a > box w/ clients. God knows what will happen. I could show you entire engineering departments that insist on confusing development and production. Running a test daemon on an alternate port is hardly as ridiculous as changing live code. I would never run KDE on a "production" server, but bet there are quite a few people who would. (Yes, I said "server.") Guess what, Debian lets them. > Now I do agree with your initial statement, not all things should conflict. > wmcdplay and xmcd both play cd's -- they dont conflict. However a deamon > provides a known service that only one should be performing at ALL times. That is a very narrow viewpoint. I am looking right now at a machine with 4 inetd.confs (one for each IP). This is FreeBSD, so they can do that. They aren't running anything on the auth ports (and there are 4 auth ports--1 primary IP, 2 aliases, and 1 localhost). They could quite easily run 4 different identds out of the four different inetds, with no conflict except the one in your mind. Now, of course, Debian's inetd doesn't support binding to specific IP, but hopefully that will be fixed in future.
