Hi,

is it possible to not get sidux-kernels or only stable, testing or sid-Kernels? - but the Community driven Kernels from Parsix, Kanotix, Dreamlinux or a other DebianDistro which provides Apt-kernels????

Thx Miltonjohn
Back to top

It's possible if and only if the following conditions are met:

The distro has a linux image metapackage available, like these:



This metapackage is NOT dependent on any specific release version, AND it must be specific to the platform type, ie, 32 bit or 64 bit. smxi parses this metapackage to determine the current apt kernel version. No other method will be considered for apt kernel handling.

Also, the distro must have a consistent, easy to test for source string in /etc/apt/sources.list, ie, it contains the term 'mepis', 'kanotix', parsix, whatever, that remains constant release to release, for those distros, like mepis, that use small frozen pools for each major release.

What I won't involve myself with here, and I say this from having now far too much experience tracking a variety of things, is anything that cannot be handled dynamically, using the above methods, which is what smxi now uses to handle all apt type kernel installs.

In other words, a new debian based distro is a one time addition, requiring no further modifications or work, which means the distro has committed to a standard, debian compatible syntax and method for its kernels, and also sticks to that method permanently, unless of courser Debian changes their's. smxi is a debian script, and any true Debian distro should work on it with relatively small alterations. If large alterations are required, in my opinion, the distro is not debian compatible. For example, Mepis uses a non standard menu.lst method and syntax, which I do NOT support, it's up to the users to make their menu.lst debian compatible.

Also, the kernel packages must also have a corresponding linux-headers-2.6.26-1-your-distro type package.

In other words, the syntax is predictable, does not require updates every new release of distro x or y. This is how sidux and debian kernels are handled, and it's the only way I'll consider handling any other distro. In other words, smxi will handle debian compatible systems, but will not handle special cases. The kernel section is very complicated, and cost a lot of development hours to get stable, and won't be altered for anything but a distro that matches the above requirements.

For example, right now smxi, if mepis had such metapackages, would have an instant on for all new mepis kernels, regardless of what type of mepis sources were used, whatever the latest package detected by testing the depends (which must list the latest linux-image-



I hope this is clear. What I won't involve myself in is anything that requires specific hard coding of kernel versions, that's just not realistic any longer long term, the only place I can justify that type of time is in sgfxi and svmi, which deal each with only one numbering type for each vm/video driver.
Back to top

Also, you can change your default kernel type used by smxi's kernel install section, in miscellaneous tweaks, advanced tweaks, it's an option, or should be for most non sidux users.

Currently the only options for defaults, of course, are the ones that are supported by smxi, which are

• none, don't show pre du kernel update section
  
• sidux, if sidux sources are present
  
• debian
  

Debian version, stable, testing, unstable, is determined dynamically based on the results of a series of tests, of /etc/issue and or /etc/apt/sources.list.

Also note above, all kernel packages are constructed like this:

linux-image-$(uname -r)
linux-headers-$(uname -r)

plus the modules, also constructed following debian standard module names, ie:
<standard module name>-$(uname -r)
ie
squashfs-modules-2.6.27-9.slh.2-sidux-686
virtualbox-ose-guest-modules-2.6.27-9.slh.2-sidux-686
virtualbox-ose-modules-2.6.27-9.slh.2-sidux-686

smxi uses one and only one set of module prefixes, it can add more to test for, but not that many more, it takes a while to run through them all now as it is for auto update and download to kernel download directory.

Also, if a derivative distro wants explicit support, I'll need a reliable, non changing way I can identify it specifically, ie: sidux has the file /etc/sidux-version, antix has the file /etc/antix-version

/etc/lsb-release, done to the standard type, would be nice but nobody seems to be using that except ubuntu at the moment.

But I need a way to detect the distro that is always correct, otherwise smxi will assume it's debian, with or without the specific other distro sources.

I hope I've covered this adequately, I think this is about everything you need to know re your larger question of smxi handling other debian type distro kernels.
Back to top