[LinuxBIOS] LinuxBIOS Debian package.

[Stefan Reinauer]

Trying to be provocative.

* Uwe Hermann <uwe at hermann-uwe.de> [060724 19:39]:
> On Mon, Jul 24, 2006 at 06:16:20PM +0200, Stefan Reinauer wrote:
> > > linuxbios - metapackage which draws in all/most other packages
> > 
> > ie. the other two?
> 
> Yes, basically. Maybe there will be more, not sure yet.

Hm. Then I'd really drop this for now until there's some
commensurability. A package count overhead of 50% is pretty much ;)
 
> > romcc is recompiled each time an image is built (which takes a lot less
> > time than running romcc)
> 
> Is this a strict requirement? Wouldn't it be possible to compile it
> once, and distribute it as /usr/bin/romcc in the Debian package?
> Are any compile-time options involved (vs. runtime/commandline options?)
 
Not exactly a strict requirement, but romcc compiles within less than a
second. This is not even 1% of the average compile time of a LinuxBIOS
image. 

Possible yes, but I have not read a reason yet, why we should do such a
change.

In fact, if we find a bug in romcc now and fix it, we can point people to
use revision XX from subversion and they are fine. I dont want to take
the overhead of explaining people they have to update their debian
package or switch the build process to use the "builtin version" for a
build time reduced by less then a second. Even opening my mail client 
takes longer than that.

romcc is a very special tool. I doubt there is too much use for it in
other projects (except _maybe_ uboot, but I doubt even that).

I would think that does not help the debian project except with regard
to staying the distribution with the largest number of packages (and
thus user confusion)
 
> lxbios should rather be an extra package as it has a different
> "upstream" tarball and author(s). But maybe linuxbios could draw it
> in, i.e. linuxbios could be a metapackage which not only depends on
> linuxbios-* packages, but also related stuff such as lxbios.
> Maybe it should have another name then, though.

...

> Also, I'll have to check the lxbios license, the DISCLAIMER file has some
> strange stuff which might pose problems for Debian...

What's wrong? The software is GPL. 
 
> > If you want to make it more
> > generic, you could call it firmware-utils or bios-utils and pack 
> > openbios' toke and detok with it.
> 
> Hm, openbios could be another package (or maybe multiple ones, e.g.
> openbios-utils?), or we could have multiple payload packages, e.g.
> 
> linuxbios-payload-openbios
> linuxbios-payload-etherboot
> linuxbios-payload-*

> Or linuxbios-payloads which contains all of them?

If at all, pack it into one of them.

Each of the payloads is between 20 and 200k. The .deb overhead is
probably more than that for most of the payloads.

Be careful when making this too finegrained. It will make it completely
unmaintainable for you, which will lead to not up to date packages
(which is a big problem in debian in general) and might in the end 
even paralyze progress.

In my opinion linuxbios should not be more than two packages:

bios-utils and linuxbios-images (and I doubt whether we really want an
-images package)

> > The build process would have to be changed to use a prebuilt romcc, and
> > I don't think this makes too much sense, as everything works fine as is,
> > and there's no benefit to doing so.
> 
> If there's no reason to build romcc for each compile it would be nice to
> only have _one_ binary in /usr/bin, IHMO (see above).
 
Again: Why would it be nice? For safing one second? 
 
> I'm not too comfortable with shipping code either (e.g. in /usr/share,
> /usr/src, or something), but I think it's a matter of convenience - users
> could have one Debian box for LinuxBIOS work and could apt-get all the
> required tools and code to work with/on LinuxBIOS.

well, they can now svn co all the code without any extra effort and
extra layer.. Is that less convenient?





-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/