| 1 |
Ned Ludd (solar@g.o) scribbled: |
| 2 |
> Compact Flash Sub Package Management is something that has yet to really |
| 3 |
> be decided and or discussed in any meaningful manor.. |
| 4 |
> It's can go any direction that _we_ the community need/want it to go. |
| 5 |
|
| 6 |
Well, I've been thinking about this a bit, so I'll toss in what I've |
| 7 |
come up with so far. I come from a commercial engineering/development |
| 8 |
house. We like version control (Well, someone does, not sure who). We |
| 9 |
do one-off's, applications, production items, mil-spec, LEO, and other |
| 10 |
stuff. (yeah, I know, great sales pitch :) |
| 11 |
|
| 12 |
With that in mind, I didn't even consider a package management system on |
| 13 |
the target (ala Zaurus/ipkg). I imagined a suite of tools for building |
| 14 |
kernels and small root images using portage. Then checking into source |
| 15 |
control things like the image build's world file, make.conf, versions |
| 16 |
list, etc. So the build can be redone from scratch with that info. |
| 17 |
|
| 18 |
That build (image & kernel to target) then becomes a static item for |
| 19 |
testing/certification/reliability/etc. Should a vulnerability be |
| 20 |
discovered in openssh-0.9.7, then a new build can be spun with the single |
| 21 |
modification (upgrade of ssh), and a regression test performed. |
| 22 |
|
| 23 |
This seems to call for some sort of world file with version numbers and |
| 24 |
*all* packages listed, deps included. Maybe an 'image' file? |
| 25 |
|
| 26 |
I can see where one would want to be able to add packages on the |
| 27 |
fly to say a wrt54g or an nslu2. Does it seem viable to do that from a |
| 28 |
host system (faster compiles, more space), and generate a new images |
| 29 |
each time? Or try to unpack the package on the fly on the target? I'm |
| 30 |
not sure I see the viability of the latter wrt diskless systems. |
| 31 |
|
| 32 |
my $0.02 |
| 33 |
|
| 34 |
Cooper. |
| 35 |
|
| 36 |
-- |
| 37 |
gentoo-embedded@g.o mailing list |
Archives