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

Re: Configuring foreign packages without qemu in order to boot a system



On Mon, 3 Sep 2012 19:44:39 +0200
Paul Boddie <paul@boddie.org.uk> wrote:

> On Monday 03 September 2012 09:20:02 Neil Williams wrote:
> > On Mon, 3 Sep 2012 02:56:28 +0100
> >
> > This is about building a linux-image_$version_armel.deb just by
> > unpacking the kernel.org tarball and running make menuconfig ; make.
> 
> Actually, I was referring to the Debian kernel packages originally, and it 
> would be those packages I'd use to build the kernel. My impression of 
> upstream "in-project" Debian packaging is that it's against policy

Policy only applies if the resulting package is to be uploaded to
Debian. Emdebian is outside of Debian Policy already, customising the
kernel packaging has nothing to do with Debian Policy.

Either you use a vanilla Debian kernel without rebuilding it, patching
it or modifying it other than via Emdebian Grip *or* you forget Debian
kernel packages, forget Debian Policy, get your kernel from kernel.org,
save yourself a huge amount of storage space and get the kernel you
want at the version you need and with only the options configured that
you can actually use.

If you want Debian Installer, use Debian kernels. If not, use
kernel.org.

Unless your resulting .deb is to be uploaded to ftpmaster.debian.org,
you don't need to comply with Policy. Comply with dpkg-deb and you're
done.

This will always break *userspace* packages because the dependencies
will get messed up but kernels don't have dependencies.

>: debian 
> directories and their contents should be separate unless the package is 
> inherently Debian, which of course the kernel is not.

And? When the result is a kernel .deb which is an order of magnitude
smaller than the equivalent Debian package *and* is for a version of
the kernel which is older than absolute current mainline, who cares?

A kernel from kernel.org *is* inherently device-specific and if that
device is to run Debian, then that package is Debian-specific. The fact
that it will never see any Debian system other than the one for which
it was explicitly configured is irrelevant.

> But then again, I don't see that going on in a kernel.org archive for 2.6.39, 
> either, so maybe this is just a matter of some other upstream packaging that 
> isn't up to the job. Either way, I wouldn't be looking in the kernel.org 
> sources for any Debian-related stuff.

Personally, I'd recommend that you reconsider that. Why waste tens of
Mb of space on a standard Debian kernel package? If you've got that
much space to burn why bother with Emdebian in the first place?

Unless you are right up to date with the Debian kernel team, there is
no point in having an all-encompassing all-things-to-all-devices
everything-turned-on Debian kernel package. None at all.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgp9jE5LuIchg.pgp
Description: PGP signature


Reply to: