On Friday 12 October 2007, dann frazier wrote: > On Fri, Oct 12, 2007 at 06:45:37PM +0200, Andrea Righi wrote: > > Geoffroy Valle'e wrote: > > > Hi all, > > > > Hi Geoffroy, > > > > > I had a quick look at the Debian packages using trunk, on x86_64. It > > > looks pretty good. The only issues i saw are: > > > - it does not use the Debian kernel, i think this is not compliant with > > > the Debian policies, > > > > This statement sounds to me always strange... BOEL is a kernel embedded > > in systemimager, the systemimager developers are able to maintain only a > > kernel for all the supported distribution (and obviously not a different > > kernel for each supported distribution, that is not a scalable solution). > > There's nothing in Debian Policy that says the Debian/SI packages > can't provide their own kernel/source binaries. But, there are a few > reasons why I consider it unreasonable to do so: > > 1) Maintenance > The debian security team only wants to do security support for one > kernel source tree. We used to maintain, if I remember correctly, > 11 different trees in Debian 3.0. This was reduced down to two in > Debian 3.1, and with etch, we're down to one. > > The way we accomplished this is to have all packages who provide > kernels build from the debian kernel source. Each time we do a > security update of the debian kernel, we simply need to rebuild > these other packages against the new source. > > 2) DFSG compliance > There are various pieces of the linux kernel that are not > DFSG-free - in fact, there are pieces that give us no legal > permission to even redistribute the code (though its an arguably > better situation today than it used to be). The debian kernel > tries to strip out these things while we try to resolve the issues > with the upstream copyright holders. If systemimager provides its > own version of the kernel source, it too would need to be > carefully stripped. > > 3) Compatability > If SI uses the same kernel source as the distro, its more likely > to work on the same systems that the distro works on. Of course, > this is the least significant of the three issues since you can > argue that the user has the option to use UYOK. > > My way of dealing with this as the systemimager maintainer was to not > include a different kernel source tree. Rather, I have a patch to the > source that build-depends on the debian linux-source- package, and > unpacks/builds that source w/ a systemimager-custom .config. > > This isn't to say its the only way to do it. If I were still actively > maintaining these packages, I'd probably be trying to make UYOK as > reliable as possible and not have to provide a kernel at all. You > could also find otherways of dealing with items 1 and 2 above, but its > a non-trivial amount of work.
Hi Dann, Thanks for the good summary of the situation. Based on what you say, i have to admit i would prefer to continue to use the Debian package for the kernel; at least for the creation of packages that are supposed to be included directly into Debian. And at the end the patch for that is pretty simple. When UYOK will be more stable, it will still be possible to change that. My 2 cents, -- Geoff ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ sisuite-devel mailing list sisuite-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-devel
