mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Michael Olbrich <m.olbrich@pengutronix.de>
To: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Building packages but not including them in the the resulting firmware image
Date: Sat, 15 Feb 2020 10:20:03 +0100	[thread overview]
Message-ID: <20200215092003.GB21732@pengutronix.de> (raw)
In-Reply-To: <05f02949-036c-15b9-41ad-fce25b8638cf@ppc-ag.de>

On Fri, Feb 14, 2020 at 06:33:51PM +0100, Mircea Ciocan wrote:
> Hello everybody, I'm trying to implement the following solution:
> 
> I have a base firmware image configuration and a number of optional
> packages, for some later choices of the customers.
> 
> I don't want to have the optional packages installed in the base firmware
> image at all, no matter the choices, but have them as installable packages
> in separate IPKs for later use.
> 
> So far, playing with the, rather sparse documented, feature of
> _collections_, I was only able to build different monolithic firmware
> versions, when I was marking the optional packages with "m" and with "y" in
> the collection file.
> 
> The separate IPKs are build, but they're also installed in the fw image, I
> didn't find a way to build them as packages and exclude form installing in
> the firmware image.
> 
> Is there currently a way to that during a single run, to build the base
> firmware and alongside of it, separate IPKs to be installed later with OPKG
> ?
> 
> So far right, now I have to do two runs, one with collections and one
> without and discard the "fat" resulting image, which is rather cumbersome.

There are multiple ways to do this. If the packages that are left out are
all defined in your BSP then you can modify the rule:

EXTRA_PACKAGES-$(PTXCONF_FOO) += foo

All extra packages are built but not added to the roofs by default.

Or you can modify the list of packages that are built into to rootfs. If
you use the regular images that means overwriting image-root-tgz.make and
setting:

IMAGE_ROOT_TGZ_PKGS	= $(call ptx/collection, $(call ptx/in-path,PTXDIST_PATH_LAYERS,configs/collectionconfig))

With something like this you could also create multiple images, with and
without the extra packages in one build. These features are documented[1]
but with a different use-case in mind.

Michael

[1] https://www.ptxdist.org/doc/daily_work_section.html#creating-individual-root-filesystems-for-each-variant

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

      parent reply	other threads:[~2020-02-15  9:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-14 17:33 Mircea Ciocan
2020-02-14 17:58 ` Mircea Ciocan
2020-02-15  9:20 ` Michael Olbrich [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200215092003.GB21732@pengutronix.de \
    --to=m.olbrich@pengutronix.de \
    --cc=ptxdist@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox