I suggest you ...

Let do_clean remove ipks too

Often one is testing a package and decides that the newer one is broken and chooses to write the recipe for an older version instead. do_clean doesnt remove the ipks/debs so re-bitbaking the package after cleaning up doesnt make a difference. do_rootfs will still pick up the newer versions' ipks, polluting the resulting image. This is especially painful when working with core packages like gtk/glib/dbus or anything that builds > 10-20 packages as one has to manually delete all these ipks. From experience, even leaving out one by mistake gave me ERRORs in do_rootfs logs and built half-complete images.

6 votes
Vote 0 votes Vote Vote
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service

    You'll receive a confirmation email with a link to create a password (optional).

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    anonymousanonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    2 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service

      You'll receive a confirmation email with a link to create a password (optional).

      Signed in as (Sign out)
      Submitting...
      • Chris LarsonAdminChris Larson (Admin, OpenEmbedded) commented  ·   ·  Flag as inappropriate

        It wouldn't be terribly difficult to implement that, though. The BitBake python package provides a module which wraps access to the "persist data" sqlite database. It could simply emit bits that are produced by tasks in the build into an entry in a table there, and clean could simply remove everything in that list.

      • Michael SmithMichael Smith commented  ·   ·  Flag as inappropriate

        This could be tricky -- let's say a recipe has PACKAGES="a b c", and you take "c" out of the list and then do a clean. You want it to remove the debs/ipks for a, b, and c, not just a & b. It means you've got to keep track of the package files that were actually generated, rather than figuring out the list during clean.

      Knowledge Base and Helpdesk