Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
#include <hallo.h>
* Robert Millan [Tue, Nov 11 2003, 02:47:14PM]:
> > > apt-get source kernel-image-* doesn't bring me the real source.
> > > Instead, if I want the real source I must be root and install a
> > > binary package. Do you deny that this is confusing?
> >
> > Non-intuitive? Yes, I grant you that. Confusing? No, I don't find it
> > confusing.
>
> Both words are valid to me.
As said elsewhere, your "solution" does not make it less confusing nor
intuitive. Please visit some basic psychology lecture before claiming
anything else.
> > But you conveniently ignored a bit of my message: after installing
> > kernel-tree-x.y.z you have the source _with_ patches applied. I don't
> > really mind either way, but I'm looking for consistency in your
> > argumentation, and I'm not finding it. You seem to claim the source
> > package is of paramount importance to you, yet I don't understand how
> > you are happy with a source package format which _does not_ give you
> > the sources of the package as used to generate the binaries.
>
> The paramount importance matter, to me, is adhering to Debian standards. Which
> means "apt-get source" brings you either the patched source or the source with
> a set of patches. Which of them happens is beyond the scope of my arguments.
BTW, how does the user know what he has to run in order to get the
source? If you still did not notice, there are much more people
wondering why "apt-get install kernel-source-<major-version>" does not
install the source which is _configured_ exactly like the kernel that
was installed by default (because of various configuration, they are
pointed to meaning of $KVERS in every FAQ). People that run "apt-get
source kernel-image-$KVERS" and wonder why there is no source are less
numerous.
> Let me spell this out for you: unless you _replace_ kernel-source-* and
> kernel-image-* and whatnot, you are not solving your perceived problem,
> you are making it worse. At some point you claimed it's not your
> intention to replace, but to offer an alternative. Having a gazillion
> variations of a theme might be a good software developing methodology,
> but I've got news for you: Debian is a distribution.
>
> My response still applies. Being "The Universal Operating System" means
> supporting lots of variations for all sort of (justificable) preferences.
And who draws the line between "justificable" and nonsense? The last
discussion similar to this one was the "mencal"-Thread but it became
quiet after the few macho comments have been forgotten and the package
has been simply accepted by the majority. Note that your case is
completely different: most people dislike your idea.
> > > In what way the presence of 136 separate kernel-* packages affects
> > > the confusability of my pair of linux-* ones?
> >
> > Oh, right, you don't want to solve a problem in Debian, you want to
> > solve it in a little corner of your mind and just ignore whatever else.
>
> Somewhat. Except that little corner pretends to be integrated within Debian.
And you still insist on taking a generic name away for your experimental
packages? You intend to use the Debian users as guinea pigs to get the
proof for a controversial concept?
> > means that you have to use "debian/rules something" to get the source
> > that's actually used to build the package. There are good reasons for
> > needing such a system, but this should be the exception, not the rule.
> > But I'm drifting...
>
> No, you're actualy right. My response was an oversight. However, this problem
> applies to all Debian packages, not just mine.
In fact, the only thing to get make-kpkg-useable source after
accidentaly using "apt-get source kernel-image-..." is removing the
debian dir. I think it is "a bit" more work with CDBS.
> > packages have build dependencies which pull _additional sources_ into
> > the tree. If you are serious about that "dpkg-buildpackage" thing,
> > then you are making no sense whatsoever, because apt-get source --build
> > foo will work fine in _both_ cases.
>
> Yes, but my concern is standarisation. Even if a standard is complicated,
> packages adhering to it are easy to understand for people who are used to
> that standard.
So you try to set YOUR own standard and make everything else fit to it?
Then please think about who maintained it before you and that they may
have to say something in that matter?
> I don't intend to support people building custom versions of my package.
And why should your users use "apt-get source" then?
> That's the general tendency in Debian, where all packages tend to be the
> most generic they can in order to support all users without need for a
> tweaked rebuild.
"Tendency" means change. I cannot remember when people stoped to ask for
a way to customize their kernel. In contrary they wanted to have mostly
unpatched kernel source for _customisations_ and so
kernel-patch-debian-... was invented.
> > > I got other private mails from well-known developers who like my
> > > proposal and pity your trolling attempts.
...
> > I could tell you I've gotten
> > private emails from well-known developers telling me that they agree
> > with my POV. But since that's not even the shade of an argument, I
> > won't.
...
> > Want to do something productive? Spend some time figuring out how to
> > merge your solution into the current kernel packaging.
>
> Why?
Because you invent shadows in order to justify your behaviour.
Big-brother arguments rarely impress Debian developers. You waste your
time in writting them down.
> > Look, as long as the people maintaining in some way the current kernel
> > images we provide (which would be basically Herbert and Manoj), I still
> > don't see why you should care.
>
> I care because of the advantages I listed.
While almost none of them could survive the first checks.
> > allows users to generate customized kernel packages for their _own_
> > needs in a manner that integrates well with the rest of the
> > distribution. Compared to this, having linux's sources in a
> > .orig.tar.gz or a binary package is peanuts.
>
> Yes, make-kpkg has many advantages at the cost of not adhering to Debian
> de-facto standards. Instead, I give priority to adhering to such standards.
> That should give an option for everyone.
Tell us what your definition of "de-facto standard" is before you
argument with them. make-kpkg is de-facto standard for me but it could
be improved in the future.
> As said before, updating the module directory within the same upstream version
> does always require a reboot.
Good point. That is why you could split the package into a kernel-binary
package and multiple modules packages, This would allow you to upgrade
modules independent from the running kernel. I have covered this in the
debian-kernel-ng plan months ago.
MfG,
Eduard.
--
Lieber zuviel essen als zuviel trinken.
Reply to: