Re: Bug#13919: exim: Package [was] badly broken! Many important files [were] missed!
[Moved to debian-devel because the bug has been fixed, and it seems to
have turned into a heated discussion between James and me. :)]
On 17 Oct 1997, James Troup wrote:
> Anthony Fok <foka@gpu.srv.ualberta.ca> writes:
>
> > > > Have you looked at debhelper? [ ... ] At least, you won't forget to
> > > > copy {pre,post}{inst,rm}.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > [...] By continually harping on about already fixed bugs, you're
> > > not doing your advocated product much good.
> >
> > When I filed the bug report, the problem had not been fixed,or at
> > least not that I know of... I downloaded exim 1.73-3 this morning,
> > and as I wrote in my follow-up, I told Mark that I'm a happy user
> > and thanked him for fixing the bug.
>
> When you wrote the underlined bit, by your own admission you were
> already using 1.73-3.
No, I wasn't. No where in that message did I say that I was using 1.73-3.
As a matter of fact, I was still using 1.73-1 at that time. I noticed
that there were no {pre,post}{inst,rm} when I did a
"ls /var/lib/dpkg/info/exim*". I saw a bunch of exim*.list, but nothing
else. That also explained why the "info exim" command didn't work at
first. I then went and downloaded exim_1.73-1.diff.gz to check what the
problem was.
> > > > Also, as I mentioned in my other message, please remove the
> > > > negative comment about debmake in debian/rules. Thank you.
> [...]
> > > It appears that not only do we have debmake advocacy, we now have
> > > debmake-speak, where negative comments about debmake are forbidden.
> [...]
> > For example, it is okay to say that "Modified debian/rules not to
> > use debmake due to potential complication caused by debstd..."
>
> That's not what Mark meant; Mark meant he didn't want to use debmake
> because it's crap, so that's what he said.
I know. I was suggesting him to write something different.
> > (Hmm... something like that??? :). I.e., give a technical reason
> > and tell in what ways debmake is deficient and therefore no longer
> > uses it.
>
> exim's debian/rules is not the place to list the deficiencies of debmake
> (apart from anything else it would make it even longer, and you seem
> to have a problem with it's length).
Okay, it was just an example. You can make it shorter. You can say
things like "Modified not to use use debmake because I don't like it."
> > Comments like "crap", on the other hand, tends to be an emotional
> > judgement;
>
> Well if Bruce can call `idiot' a ``technical term'', then crap can
> definitely be stuck under the same umbrella.
Okay, do we really have to go there?
crap(1) /kraep/ n. & v. coarse sl.
-- n. 1 (often as int.) nonsense, rubbish (he talks crap).
2. faeces
-- v.intr. (crapped, crapping) defecate
Usually considered a taboo word.
(excerpt from the Concise Oxford Dictionary)
By your definition, you may say that the word "crap" is a "biological
technical term". Isn't that nice and technical and gross? The definition
of "nonsense" and "rubbish" is more acceptable, but still, the word "crap"
is a coarse slang.
> > not to mention that you won't want your children to say that word.
> > :) It is not very good publicity for Debian either, if some users
> > decide to read the Debian source files. <smile>
>
> You obviously haven't read the source for dpkg or the linux kernel.
Okay, sure.
$ rgrep -i -r crap /usr/src/linux/*
arch/sparc/kernel/rirq.S: /* User has unaligned crap, must grab klock. */
arch/sparc/kernel/sys_sparc.c:/* XXX do we need this crap? XXX */
arch/sparc/mm/srmmu.c: * a crappy mmu. The on-chip I&D caches only have full flushes, no fine
arch/sparc/mm/srmmu.c: /* Clear any crap from the cache or else... */
arch/sparc/mm/sun4c.c:/* Scrape the segment starting at ADDR from the virtual cache. */
drivers/cdrom/mcd.c: /* Are we a double speed with a crappy CD?! */
drivers/net/3c523.c: /* this bit masking stuff is crap. I'd rather have separate
drivers/net/pt.c: * 23/02/95 cs Started again on driver, last one scrapped
drivers/net/wavelan.c: ret = 0; /* Not ready to be scrapped */
drivers/net/wavelan.c: ret = 1; /* Ready to be scrapped */
drivers/scsi/ibmmca.c: Jan 23 1996: Scrapped code which reassigned scsi devices to logical
fs/locks.c: * Scrapped free list which is redundant now that we allocate locks
net/appletalk/ddp.c: * Size check to see if ddp->deh_len was crap
net/ipv4/ip_input.c: * new frame it queues. Still crap because
I don't have the dpkg source on my computer though.
Nonetheless, does that mean we should follow those examples?
In any case, since Mark has already agreed to change the remark to
something gentler, I see no point in continuing our petty debate. (It's
fun, nonetheless... Maybe it can help sharpen my debate skill!) <grin,
duck, run>...
Anthony
--
Anthony Fok Tung-Ling foka@gpu.srv.ualberta.ca
Civil Engineering http://www.ualberta.ca/~foka/
University of Alberta, Canada Keep smiling! *^_^*
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: