Many packages in coreos-overlay are in a bit similar situation as in portage-stable - not being updated for a long time. These are harder to update as they are not simply copies of packages from gentoo.

There are two categories of packages that we have:

• Forks of gentoo packages, with our modifications.
• Our own packages:
  • Some of those probably started as forks of gentoo packages, but were so heavily modified that now count as our own.
    • For example, app-misc/ca-certificates or sys-apps/baselayout packages.

The update process of the gentoo package forks should follow a certain workflow:

• Sync with gentoo, drop the unused files and ebuilds.
• Apply Flatcar customizations.

With above in mind, I'd like to propose the following steps:

• Add an automation that could try to apply the above workflow on updated ebuild for selected packages that are gentoo forks.
  • In the beginning the set of selected packages is going to be an empty set.
• Update and categorize the gentoo forks:
  • The first update probably should be a manual thing, so we can achieve two things:
    • The automation is more likely to be able to deal with an incremental update, not an updated of a 5 years old package.
    • If the manual update is done doing the above workflow, the automation can use it as a base of followup updates.
      • It would basically be "sync with gentoo", "drop the files" (tricky!), "apply the last patch on the updated ebuild".
  • The update step may be could be skipped for packages that were recently properly updated (sys-apps/systemd, for example).
  • For each package that's a gentoo fork, I'd add a file like GENTOO_FORK, so such packages could be easily found by automation by doing cd <PORTAGE_STABLE_DIR> && find . -name GENTOO_FORK -exec dirname {} \;
    • Packages found that way could be a part of the "selected packages" set mentioned above.
• Add an automation for the rest of the packages if applicable.
• Packages like coreos-base/hard-host-depends and such won't need it.
• This will be an opportunity to find out if some other packages could be grouped together to be updated with a single automation.

This would be a part of #96.