On Saturday 13 October 2007, Andrea Righi wrote: > Geoffroy VALLEE wrote: > > 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. > > OK, looking at the resons reported by Dann now it seems more reasonable > also to me to provide different systemimager-*boot-standard for Debian, and > I also like the fact the the patch seems to be pretty simple! :-) IMHO the > important point here is to keep separated the work done in the trunk to > produce vanilla .deb packages and the work to generate .deb boot-packages > "ready" to be included in Debian, in perspective. So, the way we're doing > seems the right way: a svn repository for systemimager vanilla and a svn > repository for > systemimager-debian, that should have only the patches that can't be > included in "vanilla" due to specific distribution dependencies / > customizations. > > In any case I'm very happy to see that this thread is going forward! > > -Andrea
Sounds good to me! Regards, -- 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
