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.
> If the default BOEL
> kernel is not compliant the user can always choose the UYOK feature and use
> the
> same kernel of the distribution to install the distribution itself (or even a
> kernel of a different distribution). The kernel is a package like another, if
> we
> decide to respect this rule, we should use only the binaries included in
> Debian
> also to create the BOEL binaries: busybox, e2fsprogs, openssh, lvm, udev,
> rsync,
> etc, etc... look in make.d/ and initrd_source/make.d/ to have an idea...
There's nothing inherently "against the rules" about providing your
own kernel, busybox build, etc. But the security team reserves the
right to stop a package from entering a stable release if they believe
its unreasonable to maintain. As the member of the security team
responsible for the kernel, I've always objected to people who provide
their own kernel source. Kernel security holes are often applicable,
even in the autoinstall environment, and porting fixes can get pretty
hairy. On the other hand, I've no general objection to the userspace
components since they are running in an embedded system and most
vulnerabilities can be safely ignored (ssh being a good
counterexample).
> Anyway, I'm not a Debian guru at all and probably I'm wrong. From a SI
> developer's point of view I can say that I wouldn't like to maintain a totally
> different BOEL kernel dedicated for Debian... but it could be always possible
> to
> do so in debian/patches...
Yep, and that's the way I did it. Upstream shouldn't have to worry
about issues that are Debian-specific.
> I know :-( and I've no idea how to resolve... the point is that all the
> binaries
> in the initrd_template must be not used in practice in the distribution, but
> they'll be used only by BOEL during the installation. So the initrd_template
> is
> consistent with itself, but obviously it can't be consistent with the running
> distribution (BTW there could be differences also in terms of architecture,
> since you can install a x86_64 initrd_template also on a i386 host). IMHO the
> initrd_template should be considered somthing similar to a "binary firmware",
> shipped with the systemimager package... (I would say just like the BOEL
> kernel).
I guess I don't understand the issue you are referring to
here, probably because I haven't paid attention to the debian/trunk
work. There's nothing wrong with providing binaries for arch: foo in
an arch: any deb. That's how systemimager in debian has always worked,
but maybe that's no the issue you are referring to.
--
dann frazier
-------------------------------------------------------------------------
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
