Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 12:57:02PM +0100, Robert Millan wrote:
> > Since you like playing word games... what else do you get when you
> > do apt-get source kernel-image-2.4.22-1-k7 if not
> > kernel-image-2.4.22-1-k7's source package?
> >
> > Do you want the Linux Kernel sources with all the patches as used by
> > kernel-image-* _already_ applied and available in a well known
> > location? apt-get install kernel-tree-x.y.z.
>
> 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.
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.
> > Look, if you want to waste time, waste _yours_. OTOH, if you want
> > to take part in the discussion, do bother to address the issues
> > you are being presented with.
>
> I'd really LOVE to.
Then go ahead and address them. I'm not stopping you.
> You said: "I've got news for you: Debian is a distribution."
>
> Who started the nitpick wording?
Go back to <[🔎] 20031109011817.GA20572@racsa.co.cr> and, for a change,
_read_ what I wrote.
> > Again, your complain is that there are too many kernel-foo packages,
>
> Don't put words in my mouth. I said the current package set is
> confusing, which it is.
So that's not the source of the confusion? Then why do you bring the
number of packages into the discussion? Look at what you said in
<[🔎] 20031107191923.GA2474@khazad.dyndns.org>. _You_ are the one making
the explicit connection between "confusing" and the number of packages.
So we are back to square one where the confusion rests at the source
package format. This is starting to look like nothing but a tantrum.
> > but you are adding more. How does that improve on the problem you
> > perceive?
>
> 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.
> No, I could do the same with plain dh-make'ed templates. It'd have
> the advantage that I wouldn't have to discuss silly arguments with
> you.
1. CDBS doesn't preclude the use of debhelper. You already know this.
2. This specific point wouldn't exist, but that doesn't mean I'd
still be objecting to your ITP. If you go back and read
<[🔎] 20031107145638.GA7813@racsa.co.cr> you'll notice that I didn't
object to your particular choice of source packaging. The only
reason why we are discussing that matter is because you claim this
is a significant advantage of your work (you keep referring people
back to <[🔎] 20031107191923.GA2474@khazad.dyndns.org>, where this is
one out three points you list as "benefits")
> But your arguments are not that relevant, so I'll stick with CDBS.
Whatever.
> > Futhermore, you argue that the packaging is confusing and
> > non-standard. I take you think that CDBS is somehow standard and
> > easy to understand. It's neither. After apt-get source foo,
> > foo-x.y still _does not_ contain the sources used to build the
> > package. You have to take extra steps to do that.
>
> dpkg-buildpackage
LOL... good one. (it was a joke, right?)
If I bother to apt-get source foo, it's not because I want to
dpkg-buildpackage it right away, is it? Not having a standard way to
patch source (or unpack and patch, in cases such as libc6 and xfree86),
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...
Point is 'apt-get source linux-2.4' won't give you the sources used to
generate the binaries. If you claim this is the case, then you have to
accept that 'apt-get source kernel-image-2.4.22-i386' also does. Both
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.
Have you noticed that with your packaging it is quite an adventure to
figure out which .config file is used to build the kernel, because you
don't even bother to provide something like "debian/rules .config". I
mean, the way it was written the last time I looked at it you stuff a
whole lot of actions together in a single target. My question is how
do you intend for people to customize the kernel image using this
method (I could already have an answer to this if you had _bothered_ to
answer the question of the target userbase)
> > And since there are a couple of these hacks floating around, how
> > to get the unpacked patched source is non-obvious.
>
> It's as easy as in the rest of packages in Debian, no more, no less:
> Read debian/rules.
Get real.
> It's easy for people who are already used to Debian de-facto
> standards. Since I am and you're not [1], that makes a difference.
> Therefore don't expect to understand it.
Mind keeping this at the technical level? Tell me when you want to
come back up here, because I'm not going down there.
> > Debian provides a _distribution_. In this context less is more.
> > We have a gazillion emacs (to pick a random example) packages
> > because there are _users_ for these packages who _do_ require the
> > different versions. This is not about "survival of the fittest",
> > this is about satisfying users' needs.
>
> Some people publicly said in this thread they like the package.
> Herbert said he likes it at least as an experiment.
People "liking" a package don't create a _need_.
> I got other private mails from well-known developers who like my
> proposal and pity your trolling attempts.
Am I supposed to be impressed by that? 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.
> I responded to this before. We don't provide the Linux kernel
> packaged as a standard Debian package.
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. Next thing we know is you are going to
repackage xfree86 because you don't like that tarball-in-tarball thing.
If you have an interest the binary images, I don't see why make-kpkg
doesn't satisfy your needs. If you absolutely don't want sublevel (the
z in x.y.z) in the package name, I can't believe patching make-kpkg
would be that hard. make-kpkg is not only well-known and tested, it
_already_ deals with Debian's supported architectures and it _already_
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.
> > without adding any significant value for users and along the way
> > creating more problems (you still haven't addressed the question
> > of how you satisfy the reboot requirement on upgrades, among
> > others).
>
> http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00638.html
Mind giving me a message-id next time? oh... that. I already replied
to Jamie.
> > Up to this point, the only reason you have provided for this new
> > packaging is satisfaying some anal-retentive need of yours
> > regarding the source package organization.
>
> Don't you feel ashamed of liing so blatantly? I provided _three_ reasons:
The other "two" are not something I see as reasons: people already
tried to explain to you why there's a different source for each
architecture. If you want to correct that within the current
framework, you are more than welcome to do so. The automatic upgrades
thing, I thought I already said I consider that to be _bad_.
So, the only reason that remains is the source package thing, and I
still don't see that as a strong one. If you see maliciousness in my
words, that's your problem.
> But certainly, you must be very scared of that possiblity, since
> you're wasting your time and inventing bogus arguments just to
> prevent it from even being in Debian at all.
(you are still going in the wrong direction, "up" man, not further
down! The fact that you have taken this personally is not helping you.
Go take a chill pill or something)
> > > > * Automatic _deinstallation_ of a working kernel (upgrade
> > > > from linux-2.4 2.4.22-1 to linux-2.4 2.4.23-1 and you
> > > > deinstall 2.4.22) which anyone who's done system
> > > > administration for longer than two minutes is going to
> > > > tell you is a _very bad_ idea.
> > >
> > > That's not an issue. I can even backup the stuff in preinst.
> >
> > You mean to have gone thru all the work of putting this stuff
> > under package management just to put yourself in a position where
> > you have to do the management by hand? That's clever.
>
> I don't have to. But I can do it as an extra feature as long it
> doesn't add more binary packages (which is what I pretend to avoid).
Make up your mind: either you provide back-ups or you don't. If you
want to avoid extra binary packages at all costs, you have to
hand-manage the files in the previously installed version.
> > And do explain it to me please: how is deinstalling a
> > known-to-be-working kernel not an issue? How do you guarantee
> > that the new kernel image is even going to boot on _any_ machine
> > where the old kernel image did?
>
> How is deinstalling a known-to-be working {libc,bash,coreutils} not
> an issue?
Is any of those packages as hardware-dependent as the kernel? I didn't
think so. Some unnoticed bug in the IDE controller code and presto:
the machine doesn't boot, you roll back to the old kernel... oh, damn!
That one is already gone.
You can see that, can't you?
> How do you guarantee that the new system is even going to boot on
> _any_ machine where the old system did?
The chances of libc6 screwing up _really_ bad and going unnoticed are
pretty slim. OTOH, the chances of a hardware-dependent bug going
unnoticed aren't.
> And as I've seen in some other message, quoting kernel-package
> generated postinst, the current packages _do_ suffer of the same
> problem.
Not in quite the same way. Like I said, kernel-image package bitch
really loud in this situation. Difference is kernel-image-* has to
bitch when going from x.y.z-d to x.y.z-d'. Yours have to bitch when
going from x.y.z-d to x.y.z'-d' (i.e. when you change the running
kernel's image or when you change the installed version)
> > That one was already addressed by other people. But that was just
> > an example, you ignored the issue itself, which means you haven't
> > thought about it.
>
> You know, I could have RTFMed inmediately and respond I know what
> System.map is, but I don't see why this insignificant argument should
> actualy waste my time in reading docs for the only purpose of proving
> I can read docs.
Come on, Robert, do read what I write. That was an _example_.
> > What about the fact that modules in /lib/modules/x.y.z are gone
> > because you just upgraded to x.y.z+1 but the _running_ kernel is
> > still x.y.z?
>
> Reboot.
Ouch. Having to reboot because that's the only way to change the
running kernel is one thing, but having to reboot because the package I
just installed is breaking stuff is a different one. We take pride in
not forcing reboots across upgrades, and we shouldn't start now. There
has been only one release that I can remember where the release notes
said "you _have_ to reboot to complete the upgrade", and that was quite
some time ago.
> > Nautilus suddenly can't read a CD because isofs is gone. I want
> > to see Takuo deal with that bug report...
>
> Now it is my fault if users send bug reports to the wrong package?
You do realize that some users might not immediately notice that
nautilus is not at fault, don't you? That there's something else that
broke? "The package worked yesterday and it's not working today
anymore". The point is that after an upgrade it's likely that modules
won't load anymore and random stuff will break because of that. If you
are happy with requiring reboots after upgrades, well, I can't argue
with that.
> You seem to be particularly good at finding problems to pretend
> they're all my fault. What comes next? World hunger?
I don't know. Is it? Then please stop it, it's not a nice thing to do
to people, you know?
> I noticed it partialy answers your question, but it was unintentional.
Oh, you mean you are _intentionally_ refusing to answer my question?
> Less risky? That's interesting. If you have some suggestions, perhaps
> you can help me improve my package.
You already said you don't want to allow multiple minor versions of the
kernel to be installed at the same time, which is, incidentally, the
fix to the problem, so your only option is some gross preinst hack.
> > > > In which case, why do you want to waste autobuilder time
> > > > providing binaries?
> > >
> > > Because we're Debian. It'd be different if we were Gentoo,
> > > wouldn't it?
> >
> > (just a footnote: you ignored "in which case", but you already
> > knew that)
>
> I apologise as it wasn't intentional. Please bring a link (as I
> always do) and I'll re-read your question.
Never mind, it was just a remark. <[🔎] 20031109011817.GA20572@racsa.co.cr>
if you want to know, sorry, I don't have the URL here.
> > I'm not sure what you are trying to say. AFAIU there's a special
> > queue in the autobuilders for security related stuff and packages
> > autobuilded that way aren't automatically uploaded to the archive
> > (whatever the girl is called doesn't like packages without source,
> > and the security team doesn't like publishing security fixes
> > before the cat's out of the bag, so AFAIUI all this is handled
> > manually)
>
> Do you understand what "infrastructure problem" means?
AFAIUI this is not completely unintentional. Go talk to Matt Zimmerman
(or any other of security people) if you care.
> Of course I am. Aren't you asking the same question as often you
> want?
Because you haven't answered it in a satisfactory way, since you are
still not providing a characterization of your userbase. Saying "the
people who like FOO in a package" still doesn't say anything about
those people's needs (or actual existence for that matter). Want to
use precompiled modules? Install kernel-image-x.y.z-w-flavor and the
modules you want. Want to depend on Debian provided kernels and track
the current default? Install kernel-image-x.y-flavor. Want to have
custom kernels available as Debian packages? Use make-kpkg. Want to
use the good old make bzImage && make install? Go ahead. Who did I
left out who's not being addressed by the current solution and is
addressed by yours? Please show me that that set is larger than just
you.
--
Marcelo
Reply to: