Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Linux Spell Custom Kernel Issues

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: David Kowis <dkowis AT shlrm.org>
  • To: SM Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] Linux Spell Custom Kernel Issues
  • Date: Sat, 29 Oct 2005 15:31:11 -0500

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

David Brown wrote:
>
> After i had thought the options through i came to a conclusion and
> i'd like
> to suggest to do it the following way:
>
> > So what I'm seeing is that you want a way to be able to install a
> kernel
> > without having to go through the selection of kernels and patches.
>
> I like the newktree and oldktree concepts. The latter lacks a way to
> untar
> (and maybe patch) the kernel by hand, since it only accepts existing
> kernel
> trees it has created by itself. That should be changed and we'd have the
> longed for debian functionality. (all /usr/src/linux-* should be
> regarded
> as possible oldktree)
>
>
> This can't happen, and the reason is because I save a file in the source
> tree that tells me what that source tree has been patched with so that I
> can generate a version for the spell, what patches to update next time.
> Furthermore there isn't any way for me to tell if a directory that was
> named /usr/src/linux-* is actually a linux kernel source that has been
> patched successfully or is even a kernel source in general.
So what if you were to save a file that denoted the directory as a
CUSTOM and it doesn't do anything with sources downloads or anything, it
would simply build it again.

>
> Newktree on the other hand should do summon, unpacking and -
> patching as far
> as the spell knows. I like to have suggested versions which have been
> tested by the sorcery team.
>
>
> s#sorcery team#grimoire team# ???
> Also I check to make sure every patch I add to the linux spell actually
> patches and compiles with my config file. Also it would be kinda hard to
> have 'suggested' patches or versions because each patch has a slightly
> different focus on development. Some patches are good for servers and
> other patches are good for desktops and yet others are provided as a way
> for users to see the development of the kernel, etc.
>
> There would have to be some sort of 'this is what I want to do' =>
> 'kernel you should use' mapping but I think that might be better as a
> wiki page instead of in the spell.
IMO, this shouldn't happen.

>
> But i'd also like to be able to provide a
> version number already available but untested by the gurus. This is
> what
> i'd understand under CUSTOM.
>
>
> Okay problems with this are what CUSTOM implies when trying to get the
> sources...
> if CUSTOM implies no source information generation or auto update
> information generation ; then
> that's fine by me and it can be done that way. Whether it should be
> done or not is a different question.
> else
> you're asking me to predict the future to download a patch that
> might have moved changed dependancies or even odder things (like the ac
> sources are 2.6.11-ac7 yet uname -r on the installed kernel is 2.6.11ac7
> and that only started with the 2.6.11-ac4 iirc)
The CUSTOM wouldn't download any sources, never. It only builds a
directory that the user is responsible for setting up.

>
> Sure, i might give a non-existing kernel version and get an error.
>
>
> of course but how confusing would this be for a beginner linux user who
> doesn't know anything about the linux kernel :\
They wouldn't use the CUSTOM then :)

>
> > I think in an abstract way saying "use /usr/src/linux as my kernel and
> > go!!" would be a good idea but I'm wondering if this should even be a
> > part of the linux spell. (I'm concerned about bloat features that
> could
> > be better implemented solutions elsewhere)
>
> The advantage of the linux spell is more than just summon and
> compile. It
> may trigger kernel dependencies and does install tracking which is nice.
>
>
> Yes I agree entirely but what I'm afraid of is that we'll have this
> monster of a spell that no one but me will be able to know exactly what
> everything is doing in the spell (kinda is that way now but I tried to
> get documentation describing the spell up publicly).
I don't know the code all that much, but I'm hoping that it wouldn't be
too difficult to skip the downloading and configuration part, and just
do a build or something.

>
> (sounds a bit like sorcery)
>
Nah, sorcery is simple. My little sister could write it ;)

> Also dependancies would be easy to fix with adding and advanced linux
> spell just trigger on both and make both the linux and linux-advanced
> spells conflict...
I don't think a seperate spell should exist... I think that would make
it too complicated.

- --
David Kowis

ISO Team Lead - www.sourcemage.org
SourceMage GNU/Linux

Progress isn't made by early risers. It's made by lazy men trying to
find easier ways to do something.
- Robert Heinlein

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDY9wPtgErhgxHMHsRAtHqAJsHFo4JEpNjvQ8tAb/muOHafD7biwCeOm0b
MaconMk1+ZloK0zGZLesy2k=
=H8Ov
-----END PGP SIGNATURE-----




Archive powered by MHonArc 2.6.24.

Top of Page