Hi Andrea,

i had a look at the problem for the package systemimager-initrd-template and i 
think i know what is the problem. A arch independent package should not 
include binaries, i.e., ELF files (typically, the result of the command file 
should not be ELF). So we have a simple solution: do something to change type 
of ELF file in our package (zipping them for instance).  I tried zipping few 
binaries, it works fine; we just need to unzip the different files when we 
install the package (pretty trivial).

Does it sound like a suitable solution? If so let me know, i have a beginning 
of a patch for that.

Note that for firmware, most of the time they do not have the problem because 
the type of the firmware is "data" and not ELF.

Regards,

Le vendredi 12 octobre 2007 12:45, Andrea Righi a écrit :
> 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).
> 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...
>
> 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...
>
> > - one package has a lot of issues: systemimager-initrd-template
>
> 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).
>
> > - few packages have warnings: systemimager-server and
> > systemimager-boot-amd64-standard.
>
> These seem to be minor issues, I think we can easily fix them directly in
> the trunk. I'll look at them ASAP.
>
> Thanks to look at the deb stuff in the trunk!
> -Andrea

-- 
Geoffroy

-------------------------------------------------------------------------
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

Reply via email to