Re: What do you want in a package manager?

[Nancy Yuen <yuenn@google.com>]

[-- Attachment #1: Type: text/plain, Size: 2907 bytes --]

On Tue, Jul 21, 2020 at 8:17 AM Patrick Williams <patrick@stwcx.xyz> wrote:

> On Tue, Jul 21, 2020 at 12:57:00AM -0700, Nancy Yuen wrote:
> > I'm looking into package management for BMCs in our fleet.  I'm wondering
> > who else is interested in this, does it make sense for OpenBMC.  What
> kind
> > of features are important?  What kind of package format (rpm, deb,
> > something else)?
>
> We've similarly started playing with package management at Facebook.
> One of the reasons for us doing it is that we still have Python
> installed in the image and are running out of space, so we're moving
> some of the debug tools into packages that can be side-loaded as needed.
> We've also implemented 'ptest', which allows you to create packages
> containing your unit tests and run them on a real machine.
>

Our first use case is loading fw packages for other system components
managed by the BMC, so not code directly run by the BMC.  But I can see it
extending to other things, daemons we want to update independing etc.  We
are also running out of space, exploring secondary storage options.  I
think that's primarily where the package manager will be managing packages
in Google systems.  The BMC flash will have a basic core firmware image,
and load other packages from secondary storage.

How far have you gotten with package management?  What have you considered?


>
> We found that we had to switch to ipkg instead of rpm because the extra
> things rpm needed were too big to fit.  I recall it was on the order of
> 5MB of content needed to make rpm work and ipkg was almost free. [1]
>

Today Google has a custom package format but I want to see what other
options make sense in the wider OpenBMC community.  I'm not familiar with
ipkg so I'll take a look.


> One issue you'll want to be aware of, that many of our recipes have, is
> that they often are missing:
>
>     PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> This causes the package to be specified as relevant for a generic ARM
> system, matching the architecture revision of your underlying AST2xxx
> chip, rather than your particular machine.  Any package which can be
> customized for a particular machine (such as by machine-specific compile
> flags, or YAML/JSON files) should have the above variable set so that a
> package compiled for Witherspoon cannot be installed onto a Zaius.
>
> If you look under your Yocto build tree under `tmp/work` you'll see
> `arm1176jzs-openbmc-linux-gnueabi` and
> `witherspoon-openbmc-linux-gnueabi`.  I suspect at least most of the
> phosphor-* packages under the arm1176jzs subdirectory are likely candidates
> for having this PACKAGE_ARCH fixed.  We might want to simply add it to
> any '.bbappend' we do in a machine layer.
>

I wasn't aware of that, thanks!


>
> 1.
> https://github.com/facebook/openbmc/commit/43430d38dfd0e5557f96940547594e01373f863e
>
> --
> Patrick Williams
>


----------
Nancy

[-- Attachment #2: Type: text/html, Size: 4181 bytes --]