Re: syspkgs and kernel

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

>> This means we need pkg_add(8) which handles version correctly.
>
> What do you mean here? Is there anything required that the current 
> version handling of pkg_add(8) doesn't cover?

pkg_add(8) as a tool (TOOL_PKG_ADD).

Think you have 1,000 production hosts and keep their image identical (except
config files and packages).  You'd want to keep the master copy,
DESTDIR.myproduct, in your dev box.  You install syspkgs into DESTDIR.myproduct,
create a filesystem archive / image, test it in your dev target.  If OK you'll
distribute it.  syspkgs installation is done in a dev box, meaning pkg_add(8) 
has
to be part of TOOL_*.

>>      - installation
>>        - user deinstalls the old kernel-dependent syspkgs
>>        - user deinstalls the old kernel
>>        - user installs the new kernel
>>        - user installs the new kernel-dependent syspkgs
>
> Personally, I'd prefer to not drop an old kernel (and modules) until i  
> know the new one works. And maybe not even then.

Hmm, good point.  I think handling kernel syspkgs specially & keep some copies
is acceptable.  Maybe kind of "alternatives" using hard-link, or like that.

It would be useful to install "rescue" kernel too; a small MONOLITHIC good
enough to recover corrupted /.

For modules, they have one namespace for one kernel-version.  They may have
multiple versions for one kernel-version.  Think "kmod-usb-5.99.22.tgz" for
kernel>=5.99.22<5.99.23.  It fixes a bug and versioned up to
"kmod-usb-5.99.22pl1.tgz".  If you install the new one (5.99.22pl1), the old
one (5.99.22) is replaced.  Considering modules' granularity, I think this
would be a good compromisation.

Masao

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635