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

Re: kernel-package/kernel-image was Re: New kernel packages available



> > > I don't like dependencies, and kernel-patch is one extra to build the
> > > images. The kernel-image packages is from the method the same as for
> > > i386 and alpha. Without the dependencies we must not play with debhelper,
> > > kernel-package and other possible buggy packages. 
> > 
> > I have a working powerpc kernel-image solution.  I see this thread never
> > came to a resolution so we better do it now.
> > 
> > kernel-patch approach allows one to add other generic kernel patch packages
> > into the build easily.  On the other hand, it requires a bunch of
> > dependencies.
> 
> Well, one thing here is a style/attitude issue - adding additional
> dependencies for the kernel build is not such a bad thing, and it means
> that there is a central place to fix such problems instead of a host of
> kernel-image packages.  Kernel-package is a complex piece of software
> with a lot of potential for problems, but I still think it is a better
> idea to use that.

The kernel-package package should be for end-users. If we think about this way
we don't need the kernel-patch package, because it makes no sense if we put the
patch(es) in another place then the kernel-image package, where we build the image(s).

If we want a new image (with the old way) and we need a little patch for the
kernel-package and then also for kernel-patch, we must wait for manoj to accept this
patch and upload the newer kernel-package. After that we must play with the 
kernel-patch _and_ the kernel-image package. In my eyes this is a horror cenario. 
This is a very bad style for programming and projecting.  

Thats the reason i don't like such dependencies. One package (the kernel-image-powerpc)
is enough. You must not wait and the turnarounds are much faster.

> that the Universal IDE patch would apply cleanly.  We should definitely
> sit down and figure out what patches we need.

Yes.

> > Comments?  What can the kernel-patch approach really do that kernel-image
> > can't?
> 
> Well, one of the motivations for the kernel-patch packages, if I
> understand correctly, was the x86 IDE kernel flavor (although I'm
> greatly confused, as I can not find the IDE patch package any more, so
> I may be misremembering).  This patch now applies to powerpc as well;

No, the idea for the kernel-patch approche (inventet by me) was to split
the dawm i386 centric off. Before the kernel-patch and the _new_
kernel-image method, you couldn't build an image for powerpc. I'll now
(as the maintainer for the powerpc kernel-patch package) remove this 
package. The kernel-patch package has nothing to do with x86 stuff. 

> in fact, I need it to boot my desktop.  And, being an occasional kernel
> hacker, I've also got a few local patches I regularly apply.  Thus I
> would prefer to do kernel packages in a way that easily supports
> building with alternate sets of installed patches.

Doit in the kernel-image package, much easier in this package as to
play with serveral other packages.

> I think it's more useful, on the whole.

No! For an example: How will you remove older kernel-patches from
/usr/src/kernel-patches/* ?   Note: we have no kernel-package-base,
that will generate (and also delete) the arch directory.


Regards,


     Hartmut


Reply to: