#include <hallo.h>
* Carsten Hey [Wed, Feb 04 2009, 01:15:51AM]:
Going deep ad-hominem now? Fine, I can do it too.
> > > $ apt-cache show squashfs-modules-2.6.26-1-amd64 | grep '^Depends'
> > > Depends: linux-modules-2.6.26-1-amd64
> > > $ apt-cache showpkg linux-modules-2.6.26-1-amd64 | grep -A1 '^Reverse
> > > Provides:'
> > > Reverse Provides:
> > > linux-image-2.6.26-1-amd64 2.6.26-13
> >
> > FYI: proof by example is generally considered void.
>
> This was not a proof, this was a example (one of many), as you requested
> in <20090203195047.ga19...@rotes76.wohnheim.uni-kl.de>.
Go and reread <20090203202426.gf8...@foghorn.stateful.de -- if you put
examples after "e.g." so.. well, those examples obviously belong to this
sentence (of yours).
> > > > Second, this task is not about stuff in Lenny but stuff which has
> > > > been
> > > > added by the user/admin of the local system.
> > >
> > > Using m-a a-i? If yes this sound more like a bug in m-a since the
> >
> > RTFM. Please. ASAP.
>
> How many people did already tell you about you lack of social skills,
You didn't know who is setting the dependencies and boldly pulled
another scapegoat (m-a). IMHO an RTFM hint is more than justified and
now it's time for you to realize that.
> your lack of reading skills (e.g. the requested output of dpkg -s is
> still missing) or your general lack of clue?
Quote from my original report: "The problem: foo-module-$KVERS has no
Depends on the kernel module.". If you look for someone lacking reading
skills, look into a mirror.
> > m-a or kernel-package do not set dependencies, particular package
> > maintainers do. And the first non-official package coming to my mind is
> > the best counter-example:
>
> broken:
>
> > $ apt-cache show nvidia-kernel-2.6.28 | grep Depends
> > Depends: nvidia-kernel-common (>= 20051028+1-0.1)
>
> non-broken:
"broken", wow, impressive wording! But apparently there is a lack of
imagination for the use cases between them, like the obvious one:
kernels that are NOT packaged with kernel-package (resp. kernel team's
replacement).
What you do is redefining the scope of my feature request IN ORDER to
declare it as void WRT to the now changed conditions. Please stop doing
that.
> But this non-bug is about the official deborphan and non-official
> packages are not supported, thus closing it now.
"not supported"? Well, my request made enough sense to the previous
maintainer of the package; now if YOU come and REDEFINE the rules then
please tell this upfront instead of making hot air about "the official
packages", "not supported", "broken", ...
> If you want to make a non-official fork of deborphan please substitute
> every appearance of pike (--guess-pike is rather useless for most
> people) with kernel, PIKE with KERNEL and strcat(guess,
> "^pike[[:digit:].]*-|"); with strcat(guess, "-modules-[[:digit:].-]+|");
> (untested) or grep for pike and check the necessary changes yourself. In
> the letter case you also need to adapt things like #define GUESS_ALL.
> Please use a SVN snapshot when you do this to avoid unnecessary work
> since these things have changed since 1.7.27.
Are you kidding? Responding to a wish for a public feature with a
suggestion of making a private fork, even knowing how easy it is to
implement?
*headshaking*
Whatever, do what you want. I don't have enough spare time for
flamewars about such nuissance.
Regards,
Eduard.
--
<mrvn> rofl, I like tha bug
<mrvn> He probably set it to grave to keep it out of testing too.
<towo> debian_.de_, mrvn. ;)
* mrvn schmeisst mal ne Runde Babelfische in den channel.
<mrdata> '' Er stellte es vermutlich auf Grab ein, um es aus auch prüfen heraus
zu halten. ''
<mrdata> ahja... :)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
