[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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: