Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Mon, Nov 10, 2003 at 11:26:43AM -0600, Marcelo E. Magallon wrote:
> >
> > 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.
> 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.
> > 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.
Please be more specific. Do you refer to:
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.
> > > 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.
There are two paragraphs on that mail referring to the "confusion" issue.
You're ignoring the first one, which doesn't refer to the number of packages.
> > 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.
> > 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")
I don't recall claiming that using CDBS is a significant advantage in my
package. Certainly, in <[🔎] 20031107191923.GA2474@khazad.dyndns.org> there's
no reference to CDBS.
> > > 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...
No, you're actualy right. My response was an oversight. However, this problem
applies to all Debian packages, not just mine.
> 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.
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.
> 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)
I don't intend to support people building custom versions of my package.
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.
> > 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.
The quote looks much worse after you cut off the [1] expando. However, at
this point I admit it wasn't the right thing to say. My apologises.
"[1] Your reasoning shows either you're not used to them, or you're plainly
trolling. I'll assume the first at your convenience."
> > > 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 disagree. I don't need Debian at all myself, but I like it.
> > 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?
No. I don't even pretend that you believe it.
> 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.
Up to you.
> Want to do something productive? Spend some time figuring out how to
> merge your solution into the current kernel packaging.
Why?
> > 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.
I care because of the advantages I listed.
> 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.
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.
> > > 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.
We already discussed this, so please provide references. My concern is
autobuilding, not having a different source for each architecture.
> If you want to correct that within the current
> framework, you are more than welcome to do so.
But in the current framework, packages aren't autobuilt normaly, so correcting
this wouldn't be significant for what we're discussing.
> The automatic upgrades
> thing, I thought I already said I consider that to be _bad_.
Why?
> 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.
The only reason I see maliciousness in your words is because you discarded
two of the advantages without providing a link to the discussion on which
they were proved bogus.
> > > 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.
That's what I had in mind.
> > 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?
Uhm.. yes. It makes sense. That makes backups necessary.
> > 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)
Ok.
> > > 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.
It doesn't matter how do you manage backups. If you change /lib/modules/x.y.z
you have to reboot one way or the other.
> > > 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".
I have seen this in other places. We have a "reassign" command for that.
> 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.
As said before, updating the module directory within the same upstream version
does always require a reboot.
> > 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?
Heh.
> > I noticed it partialy answers your question, but it was unintentional.
>
> Oh, you mean you are _intentionally_ refusing to answer my question?
Yes. You asked me to carachterise my target user base, at which I can only
respond "those who like the advantages".
> > 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.
The preinst solution sounds fine to me.
> > > > > 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.
Oh, I see. Well, my target userbase will generaly use autobuilt binaries and
only play with the source when there's a reason (other than costumasation) to.
> > > 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.
No need to, I believe what you say. Then the "autobuilder advantage" wouldn't
be "specialy important for security updates" as I claimed.
> 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.
You're asking me for the impossible. I listed the advantages and acknowledge
there are disadvantages, so I can just say those who like the advantages at
the cost of the disadvantages are part of my target userbase.
So with the exception of the few people (1?) who posted here explaining their
interest in the advantages, I can't give you a response on that. However,
for the matter of finding out wether there will be much people in that
userbase, there's the Popularity Contest.
--
Robert Millan
"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."
-- J.R.R.T, Ainulindale (Silmarillion)
Reply to: