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

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Sun, Nov 09, 2003 at 02:40:11PM +0100, Robert Millan wrote:

 > The packaging method is the whole point. And indeed, some people like
 > the ability to do standard things like "apt-get source foo" and get
 > foo's sources.

 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.

 > >  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.
 > You just messed up. Debian is "The Universal Operating System". At
 > least, we claim that in the website title.

 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.  If all you are going to do is nitpick on
 wording, piss off.

 Again, your complain is that there are too many kernel-foo packages,
 but you are adding more.  How does that improve on the problem you

 > >  > >  Confusing to you.  Sounds like a job for a README.  Do
 > >  > >  realise that CDBS (or similar hacks) also require familiarity
 > >  > >  with the particular system.
 > >  > 
 > >  > You're deliberately mixing things that hold no relation.
 > > 
 > >  I beg your pardon?
 > No. Specialy because you cut off the relevant part of my reply:
 > "The way debian/rules is created differs from package to package all
 > over Debian. It's not new that when you read a debian/rules you might
 > not be familiar with it (which, btw, is one of the reasons why CDBS
 > exists)."

 I was addressing this:

      - Easy understanding of the package. Developers looking at the
        package will find every piece in the place Debian packages
        normaly put it.  The binaries are in .deb, pristine upstream
        sources are in .orig.tar.gz, the debian/ dir is in .diff.gz

        I could finaly work out where everything is, but the current
        situation is confusing. [...]

 and keeping in mind that you have a problem with the current way the
 kernel is packaged, I have to conclude that you think that using CDBS
 is a better choice, because if it isn't you wouldn't be using it in the
 first place.  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.  And since there are a couple of these
 hacks floating around, how to get the unpacked patched source is

 Now do go ahead and do tell me that the packaging is "easy to
 understand".  Define "easy" then, because with the information I have
 at hand the only reasonable interpretation is "easy for Robert Millan
 to understand".

 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.

 > >  You have a problem with the current source packages, and you have
 > >  said the source packages for kernel-image-* are confusing, haven't
 > >  you?  I don't see how this is unrelated.  Now, if you had answered
 > >  my question, maybe I could understand what you want to achieve,
 > >  but you haven't.
 > There's a difference between the whole structure of a package set
 > (wether it has 107 components or just a pair of them) and the
 > structure of a debian/rules file. You're pretending that using a
 > particular style of debian/rules is a reason for objecting an ITP,
 > but it's not.

 My objection is based on the fact that you are packaging something that
 we _already_ provide, 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).  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.

 > >  Have you _looked_ at the kernel-patch-* packages?  The 70 of them?
 > >  I guess you realize these things aren't compatible with each
 > >  other?  I assume you mean only kernel-patch-debian-*, in which
 > >  case you improve the situation only marginally (or you are trying
 > >  to confuse people by bringing the 70 kernel-patch-* packages into
 > >  the discussion)
 > First, there's a total sum of 136 packages, from which kernel-patch-*
 > are 70 of them. From these 70, only kernel-patch-debian-* and a pair
 > of architecture-specific patches fit in my scheme.

 So you are not going to significantly reduce the number of
 kernel-patch-* packages, which means you don't solve _that_ part of the
 problem you perceive, doesn't it?

 > All of these packages are already existing and I don't plan to
 > replace them. Again, you're mixing the question on wether I'll
 > provide 70 linux-patch-* packages (which I won't), and wether I'm
 > going to rely on them.

 I am not.  Your scarce wording leads me to think you consider the
 number of kernel-patch-* packages a problem.

 Let's have a look at the number of kernel-(image|source) packages for
 i386, and let's just assume that your scheme succeeds and becomes the
 preferred way of distributing Debian kernels, what would we have?  The

kernel-image-2.2.20-reiserfs    | remains in some form AFAIUI
kernel-image-2.4-386            | remains (different name, same thing)
kernel-image-2.4-586tsc         | gone, I guess
kernel-image-2.4-686            | gone, I guess
kernel-image-2.4-686-smp        | gone, I guess
kernel-image-2.4-k6             | gone, I guess
kernel-image-2.4-k7             | gone, I guess
kernel-image-2.4-k7-smp         | gone, I guess
kernel-image-2.4.18-bf2.4       | gone
kernel-image-2.4.22-1-386       | gone
kernel-image-2.4.22-1-586tsc    | gone
kernel-image-2.4.22-1-686       | gone
kernel-image-2.4.22-1-686-smp   | gone
kernel-image-2.4.22-1-k6        | gone
kernel-image-2.4.22-1-k7        | gone
kernel-image-2.4.22-1-k7-smp    | gone
kernel-image-2.4.22-speakup     | remains, addresses special needs
kernel-image-2.6.0-test7-1-386  | gone
kernel-image-2.6.0-test9-1-386  | remains in some form AFAIUI
kernel-source-2.2.25            | gone
kernel-source-2.4.19            | gone
kernel-source-2.4.19-hppa       | gone
kernel-source-2.4.20            | gone
kernel-source-2.4.21            | gone
kernel-source-2.4.22            | gone
kernel-source-2.6.0-test7       | gone
kernel-source-2.6.0-test9       | gone

 That certainly looks good.  You just got rid of a bunch of very large
 packages, that I grant you.  But since people _seem_ to want to have
 this architectural flavors, the "I guess" ones aren't really gone.  And
 I still don't see how the "confusion" has been reduced so dramatically.
 I don't see the kernel-image-x.y.z-flavor packages being gone as a good

 > >     * 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.

 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?

 > >     * A package which requires a reboot on updates
 > Oh, now I'm suposed to fix that, too? Bitch upstream for a run-time
 > updatable Linux kernel.


 That's not the point, I thought that was obvious, sorry.  The point is
 how do you guarantee that this reboot is going to happen?

 > >     * A package that might break other packages when it's upgraded
 > >       (change System.map, don't reboot, and watch stuff stop working)
 > Actualy, I didn't even bother to provide System.map, and my system
 > works quite well. I can add it if you bring me a reason to do so,
 > though.

 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.  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?  Nautilus suddenly can't read a CD because isofs is gone.
 I want to see Takuo deal with that bug report...

 > >  So you want to nuke the -386 and -586 and -k7 and whatnot
 > >  packages?  I couldn't care less, I don't use any of those, but I
 > >  guess there are some users who appreciate them.
 > I don't target at these users. They should use the current packages
 > instead.

 Ah, thanks, at least a partial answer to my question.  See?  It didn't

 > >  But do tell me then, you are not targeting newbies, are you?
 > >  Because if you don't target them, I don't know what kind of user
 > >  will want automatic upgrades of the kernel.
 > Like, say, me. If you call me a newbie at this point we can finish
 > the discussion.

 What?  Is "newbie" an insult now or something like that?

 If you want your kernels automatically upgraded, fine, your problem.
 But don't inflict that on the rest of Debian.  You _can_ have that
 right now, in a less risky way.

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

 > It's clear the packages taken by autobuilders hit the archive before
 > the ones compiled manualy. If that doesn't happen then we have an
 > infrastructure problem.

 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)

 > Just like it happens in the rest of Debian, specialy if you run
 > unstable.

 Uhm... no.  Unstable is a special situation where we _advertise_ that
 it _will_ break at any time.  But stable is something else.  Systems
 running stable should not break on updates.  You can't prevent it but
 you should try to.

 > And then tell me what you think "us" means in that phrase. I
 > apologise if it sounds ambigous, but you can still deduct it from the
 > context.

 "us", Debian, the bug could have happened on any Debian system.  The
 fact that a subset of installed systems won't be seeing it, doesn't
 mean it can't happen (i.e., that it can be prevented).  You can't
 express a dependency on a particular kernel version with dpkg, can you?

 > Yes. And you're not entitled to tell me when I shouldn't duplicate
 > someone else's effort. I do it because it's worthy of doing.

 And you are welcome to do whatever you want in your $HOME.  I'm not
 telling you what you can and can't do with your time.  But placing the
 package in the distribution is a different thing, there you _are_
 duplicating effort.

 > >  I think it's more than justified to ask you who you think your
 > >  users are.
 > Sure. My users are those who like the advantages described in:
 > http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html

 Sure, you are free to keep quoting that URL as often as you want (which
 still doesn't answer the question in a satisfactory way), but that
 doesn't change the fact that the objection to your ITP still stands.

 > Or did you think I pretend to insert my package into stable directly?

 Gee, it didn't occur to me that your first upload was going to be to
 unstable or experimental... /like every other maintainer does with
 every other package in this project/.


Reply to: