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

Debian or vanilla kernel - best of both worlds possible?



Hi,

in the last months, a lot of things have happened with regard to
kernel development and packaging. I have been trying in the last weeks
to assess these changes' implications on me as a somewhat advanced
end-user who is accustomed to building custom kernel .debs from the
upstream sources.

Let's summarize what has happened. Please correct me if I have gotten
anything wrong:

- Herbert has resigned. The Debian kernel is now maintained by a group.
- 2.6 Debian kernel sources use dpatch for local patches. This makes
  it easy to enable/disable single patches.
- However, Debian's new policy is to remove non-free parts of the
  kernel. This can't be done by a patch, but must be done by re-packing
  the upstream tarball, destroying the "pristine source" approach for
  the kernels.
- Kernel Upstream has basically abandoned the end user by declaring
  that the 2.6 kernels being released on kernel.org are not the most
  stable kernels, and that building kernels for use on production
  systems should be the distribution's job.

My basic question is "How do I get a stable kernel by retaining best
of all three worlds - Upstream, Debian, and my local requirements".

A possible starting point for me would be the upstream kernel sources
without the non-free firmware removed. This is necessary since
hardware vendors will say "use the lastest driver from the Linux
kernel", and I cannot argue against that my distribution had the
drivers removed.

The good news is that the Debian patch only creates files in debian/,
which will make it apply cleanly even to vanilla kernel sources. Is it
planned (documented as a committment of the kernel team) that this
will stay that way? If yes, one could check out the Debian
subdirectory without checking out the "real" kernel, which would
greatly help in reducing download volume.

Additional good news is that you guys use dpatch to actually change
the kernel source. Do I see correctly that for example
drivers-net-tg3-readd.dpatch was created because the .orig.tar.gz
already had tg3 removed?

The patch files themselves don't contain too much information about
the character of the patch. Short comments inside the patch files
themselves saying "fix local root exploit (CANxxx-yyy)" or "re-add tg3
support which was removed in orig.tar.gz", or "fix 'does not build'
type error on $OBSCURE_ARCH" would be very appreciated. There seems to
be documentation in README.Debian, but I am not too sure whether that
list is current, and I am missing the reference to the patch file. Did
I overlook something here?

During preparation of this message, a few additional questions have
popped up.

Are the .svn directories inside kernel-source-2.6.7_2.6.7-4.diff.gz
left there intentionally?

The Description of kernel-patch-debian-2.6.7 says that it should be
applied to a pristine 2.6.7 kernel. Does that still apply now that
some drivers have been removed from the pristine kernel sources? IMO,
kernel-patch-debian's description should also include some reference
that the source package uses dpatch which makes it somewhat easier to
choose patch sets.

Let me sum up: Debian kernel development has recently made a huge leap
forward. There are some questions which I would appreciate having
answered, and some docs are missing (I can deliver them if I get my
questions answered). The really bad things happening can easily be
reverted locally. Please, keep up your excellent work.

I would, however, appreciate answers to my questions. Thanks in advance.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany |  lose things."    Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature |  How to make an American Quilt | Fax: *49 721 966 31 29



Reply to: