Re: Packages should not Conflict on the basis of duplicate funct
> 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.
Reply to: