Re: Proposal for removal of mICQ package
#include <hallo.h>
Craig Dickson wrote on Fri Feb 14, 2003 um 10:06:56AM:
> He tried. He used the BTS, he used email, and there was recently a
> discussion of it here on debian-devel (though if that discussion
> post-dates the release of the code that has everyone so upset, then it
> doesn't really count; I'm not quite clear on exactly when the nasty
> code was released).
I am too lazy to go trough the complete flamewar again, but IIRC the first
time when Rüdiger was mentioned is that someone reported about someone whos
friend saw that easter-egg. So it was already to late. And I cannot remember
Rüdiger discussing _anything_ in Debian's public mailing lists, so IMO his
motivation in becoming a developer is questionable whatsoever.
> His next step should probably have been to take it to the Technical
> Committee, but apparently he either wasn't aware of that option or was
> too frustrated with the situation to wait for however long that might
> take to get a resolution. I don't condone his choice, but I understand
> the frustration.
I can understand the frustration as well, but even beeing frustrated I would
ask whether his action is worth, and stop immediately. Personal conflicts
should never be fought out on the back of the end users.
> > Maintainer isn't a user?
>
> When the maintainer is packaging the software, he is not acting as an
> end-user. He may also be an end-user, but that's a separate role which
> applies when he is actually _using_ the software, not _packaging_ it.
Well, but a good maintainer _is using_ his packages as well in order to notice
the problems faster. In this case the maintainer was fooled, a deliberate
act.
> > A software that expires silently (read: same
> > thing as bad shareware does) on certain systems is not trojaned? IMHO
> > this is something violation DSFG in the first line.
>
> You mean the non-discrimination clause? I believe that applies to the
> license under which the code is released, not the code itself; and in
So? And how do you call a case when someone distributes the software under a
DSFG-free license, and 2 months after Debian-Stable has been released, the
software begins to bother the users about registration (or so) and fails to
run otherwise? Yeah, you have the source and you can fix it, but it is still
hiden malware.
> any case the Debian maintainer could have avoided the whole problem by
> simply supplying a value for the EXTRAVERSION variable, as upstream had
> been requesting. When that variable is defined, the program functions
> normally.
> Also note that the program does not fail on certain _systems_ -- you can
> download Ruediger's own .deb package, built from exactly the same source
> code, and it will function normally. It is only the official Debian
Should this really ba an argument? Imagine, company Foo would distribute
library Bar with some tools that only work when they are installed in the
location prefered by the company. With DSFG-free software, we have the right
to fix the stupidity.
Also note that it is _not_ the same source code that you get from Rüdiger, the
additional Debian stuff is different.
> _package_ that doesn't work (regardless of what system it's running on),
> and only because the Debian maintainer persisted in not doing a simple
> thing that upstream had requested (defining the EXTRAVERSION variable).
I still fail to see the big importance of that version. Why does the upstream
need it? To Debug something? His argumentation in #180563 is odd - why should
someone report FTBFS trouble to him when the package passed all Debian checks?
And even when, why should a normal bug reporter not mention which distro he is
using? IMO the whole "problem" was extremely exxagated in Rüdiger's mind and
his judgement is not objective enough.
Gruss/Regards,
Eduard.
Reply to: