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

Re: language of choice for k-p packaging ...



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 14 Nov 2005 12:15:29 +0100
Sven Luther <sven.luther@wanadoo.fr> wrote:

> On Mon, Nov 14, 2005 at 11:46:07AM +0100, Jonas Smedegaard wrote:

> > On Mon, 14 Nov 2005 09:57:22 +0100
> > Sven Luther <sven.luther@wanadoo.fr> wrote:
> > 
> > > On Sun, Nov 13, 2005 at 10:56:40PM +0100, Jonas Smedegaard wrote:
> > 
> > > > On Sun, 13 Nov 2005 20:03:59 +0100
> > > > Sven Luther <sven.luther@wanadoo.fr> wrote:
> > > > 
> > > > > > I'm not sure about the linux-initramfs-tool part of the
> > > > > > dependency.
> > > > > 
> > > > > That is a virtual package, so future ramdisk tool can satisft
> > > > > the dependency, without needing to recompile the kernel.
> > > > 
> > > > ...but still this requires manual override
> > > > in /etc/kernel-img.conf.
> > > 
> > > No, when building the kernel packages with INITRD_CMD=..., then
> > > this will become the default, and can be overriden by
> > > kernel-img.conf. This is instead of hardcoding the values in k-p.
> > 
> > Yes, it _does_ require manual override in kernel-img.conf to
> > actually _use_ a future ramdisk tool satisfied by the virtual
> > dependency. And it seems you even agree with me (what do you mean
> > by "No"?).
> 
> Well, there are three cases : the current one where the *DEFAULT* is
> hardcoded in k-p, the one i propose, where you can hardcode that in
> linux-2.6, and chose to do it per arch/subarch/flavour even, and your
> proposal, which is more far-ranging.
> 
> My proposal should be a couple of lines of patch, nothing more, and
> would work out of the box with k-p 10.00x, while yours, altough
> nicer, needs more work and cooperation.
> 
> The idea is to use it to remove initramfs-tools from the default list
> on alpha, while not needing to conflict against initramfs-tools as it
> is done now, you see, ways less ambitious than your proposal :)

I am not talking about my FlexibleKernelHandling above. I am pointing
out a shortcoming that I believe exist wether the paths are taken from
k-p or k p.

Sure I want to address this shortcoming in my FlexibleKernelHandling,
but please let us not confuse this practical focus with my fluffy,
vague, unchallenged idea.


 - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDeHZPn7DbMsAkQLgRAkogAKCTA0QpxIZwlLgw4n/LPa113xRLlACeMV4q
wKQMLG8OgC1IbCIzpRstxb0=
=MA94
-----END PGP SIGNATURE-----



Reply to: