Trying to be provocative.
* Uwe Hermann email@example.com [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?