> > > 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
normal.
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
system.
>> 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
beginning.
Do notice that this asseveration implicitly expands your userbase to
non-i386 users, which in my book fall flat out of the category
"newbie".
>> 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?
Marcelo
