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

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

 > >  > It's not "cosmetic". The point is it has a completely different
 > >  > packaging style and philosophy. I want to package the Linux kernel in
 > >  > the same way the rest of Debian is packaged, that's all.
 > > 
 > >  Until now you have failed to provide a reason for that, other than
 > >  cosmetic reasons.
 > See:
 > http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html

 Mind pointing me to the answer I'm asking for?  Because that message
 contain two cosmetic reasons, and one non-reason:

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

 1.  You want to use CDBS, which might be a nice hack, but it's hardly

 2.  kernel-image-* contains images in a deb.

 3.  You seem to have a problem with the kernel-source-* packges, which
     I honestly don't follow.

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

 Confusing to you.  Sounds like a job for a README.  Do realise that
 CDBS (or similar hacks) also require familiarity with the particular

 >>   In my apt database, there are 136 packages that match "kernel-*",
 >>   from which 19 are "kernel-image-*", 7 are "kernel-source-*", 14
 >>   are "kernel-headers-*", and 70 are "kernel-patch-*".

 And that's a problem... why?  I don't mean to say that the situation is
 perfect nor beautiful, but please do tell me how you want to fix that.
 You have a source package called linux-x.y, and another source package
 called linux-preferences.  Generating a different kernel binary means
 having to download the source package, and dpkg doesn't support
 installing source packages, so tracking this source has to be done by
 hand.  You can't (nor want to) absorb most of the kernel-patch
 packages, so you fix nothing in that regard.  There _are_
 kernel-image-2.4-foo packages, so tracking the chosen flavor of the
 "current" kernel-image package is easy for the people that want such
 and thing (and since there _are_ kernel-image-2.4.z packages, *no*
 kernel image gets automatically _deinstalled_ which is the case with
 your packaging -- if you can't see why this is bad, please go take a
 hike).  If you add architecture flavors to your packaging, you add a
 "few" more binaries to your desired linux-2.4 scheme, thus you are not
 reducing complexity on that part of the problem either.  Why you have a
 problem with the kernel-headers packages is beyond me (since your
 scheme might eventually need this, too).

 >>  - Handled by autobuilders, which means new versions are compiled
 >>    automaticaly for all Debian architectures. Normaly, users of
 >>    non-i386 would have to wait untill a maintainer for each port
 >>    compiles it manualy for their CPU.

 Which people actually working with non-i386 architectures have tried to
 explain to you already, but you insist on shoving the problem under the
 rug without actually showing that you _can indeed_ handle the it.  As
 Daniel said, you might as well call this Architecture: i386 from the

 Do notice that this asseveration implicitly expands your userbase to
 non-i386 users, which in my book fall flat out of the category

 >>    This is specialy important for security updates. Remember DSA-358
 >>    and DSA-336, for which the security team had to build the Linux
 >>    kernel manualy for all our architectures, delaying the advisory?

 (you did notice that your package creates more work for the security
 team, right? just wondering, since you asked who "everybody" was)

 >> - Automatical major updates (the x in 2.x.y). When 2.6 is suitable
 >>   to be the default version, a simple change in -defaults package
 >>   (ala gcc) would enforce updating on all existing systems that use
 >>   this method. This prevents us from encountering ABI
 >>   incompatibility problems, like this recent one in Glibc: #215010:
 >>   Illegal instruction with 2.2 kernel

 That bug is not prevented by your scheme.  People using your packaging
 won't see it, but that's one or two universes away from what you claim.

 And for practical purposes, this is cosmetic, and solvable with
 different methods.  Ask Herbert to maintain a kernel-image-i386
 package, if that's so important to you.  It's just a few more lines in
 a debian/control file worth of work for him.

 > >  Please _define_ your target user base,
 > Those who like the advantages described in:
 > http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html

 Oh, now you sound like a broken record.

 I asked you to define your target userbase, so please characterize your
 userbase.  "Those who like what I do" is not a characterization.  What
 kind of expertise do your users have?  What kind of job do they perform
 with their Debian systems?  Do notice that your users need to be
 comfortable with several things, like CDBS and patching a kernel.
 Furthermore, you ask them to work with source packages more directly
 (which might be more complicated than just using make-kpkg).  What can
 you do with your scheme that you can't do with kernel-package?

 > Read what the current Linux kernel maintainer says:
 > http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00452.html

 I read that, thanks.  I was dissappointed that Herbert thinks that
 experimenting with packaging methods in this way is good, in particular
 I wonder if he realizes that once a package is shipped with a stable
 release, getting rid of it is a PITA.  Herbert didn't actually say he'd
 like to see this as part of a release (he only said "hosting"
 actually), but I'll give you the benefit of doubt on that.

 > >  So, your package _can't_ be the default kernel package, because
 > >  that needs to be supported on all architectures the installer
 > >  supports.  Which makes me wonder again: what is your target
 > >  userbase?
 > Those who like the advantages described in:
 > http://lists.debian.org/debian-devel/2003/debian-devel-200311/msg00414.html

 Oh, come on, did you even read the question?


Reply to: