Skip to content

Optional PkgForge backend for Penguins-Eggs (external adapter, no core changes) + Using PkgForge as a build/cache backend for Penguins-Eggs ISOs (external adapter) #153

@Interested-Deving-1896

Description

@Interested-Deving-1896

file_00000000392871f8a131f5afd13adb90.png

[ Hello 👋

This issue proposes an optional, external integration between
Penguins-Eggs and PkgForge, implemented as a small adapter repo.
No core Penguins-Eggs code would be modified unless explicitly agreed.

Summary

The idea is to allow Penguins-Eggs to consume PkgForge-built artifacts
as a package backend, alongside existing apt/apk/etc workflows.

Penguins-Eggs would remain fully independent and distro-focused;
PkgForge would simply act as an optional build + cache source.

What this enables

  • Reproducible ISO builds
  • Reduced reliance on host distro repos
  • Cleaner Alpine / non-Debian workflows
  • Artifact caching and reuse
  • Experimental distro-agnostic Eggs images

What this does NOT do

  • No repo merge
  • No rewrite of Eggs internals
  • No replacement of existing package managers
  • No new mandatory dependency

Proposed approach

  • External adapter repo (pkgforge-eggs)
  • Optional pkgforge backend selected via CLI
  • Declarative manifest shared between projects
  • Eggs remains authoritative over snapshot + ISO logic

Status

This is currently a design + PoC proposal.
Feedback on scope and boundaries is welcome before any implementation.

Thanks for your time, and happy to adapt this to Eggs’ preferred workflow. ]

ChatGPT Chat Link : [ https://chatgpt.com/share/6983fc51-dbfc-8012-9a6c-d861f2750639 ]

Initial Inquiry : [ Could you assist with integrating, wrapping, merging & collaboration between Penguins-Eggs & PkgForge, please & thanks in advance.

https://github.com/pieroproietti/penguins-eggs

https://github.com/pieroproietti/penguins-packs

https://github.com/pieroproietti/fresh-eggs

https://github.com/pieroproietti/penguins-eggs-ppa

https://github.com/pieroproietti/penguins-alpine

https://github.com/pieroproietti/penguins-bootloaders

https://github.com/pieroproietti/eggsmaker

https://github.com/pieroproietti/pengui

https://github.com/pieroproietti/basket

https://github.com/pieroproietti/easy-menu-system

https://github.com/pkgforge

https://github.com/pkgforge/soarpkgs

https://github.com/pkgforge/devscripts

https://github.com/pkgforge/pkgs.pkgforge.dev

https://github.com/pkgforge/bin

https://github.com/pkgforge/aeris

https://github.com/pkgforge/soar

https://github.com/pkgforge/nix-appimage

https://github.com/pkgforge/sbuilder-go

https://github.com/pkgforge/sbuilder

https://github.com/pkgforge/squishy-rs

https://github.com/pkgforge/bincache

https://github.com/pkgforge/pkgcache

https://github.com/pkgforge/build-system

https://github.com/pkgforge/store.pkgforge.dev ]

Initial Response :

[ Oh this is a very good pairing. Penguins-Eggs and PkgForge actually complement each other almost suspiciously well 🐧🥚⚒️
I’ll break this down in a way that’s practical, realistic, and collaboration-friendly—not a big-bang merge that nobody wants to maintain.


Big picture: what this collaboration should be

Penguins-Eggs = system snapshot + live ISO + distro crafting

PkgForge = universal package production, caching, and distribution

Together, they can form a full lifecycle:

Build system → package artifacts → cache/store → OS snapshot → ISO/image → redistribution

Think of Eggs as “what the system becomes”
Think of PkgForge as “how software gets built, cached, and shipped”


  1. Conceptual integration map

Penguins-Eggs side (what Eggs already does well)

Component Role

penguins-eggs Snapshot → ISO
penguins-packs Package grouping
fresh-eggs Minimal base seeds
eggsmaker Build orchestration
penguins-alpine Non-Debian proof
basket Package sets
pengui UI frontend
bootloaders, easy-menu-system Boot UX

PkgForge side (what it adds)

Component Role

soar / soarpkgs Universal package format
sbuilder(-go) Reproducible builders
bincache / pkgcache Artifact caching
store.pkgforge.dev Distribution layer
nix-appimage Cross-distro app builds
squishy-rs Compression / FS tooling
aeris Infra glue


  1. Recommended integration strategy (no monorepo!)

❌ Don’t

Hard-merge repos

Rewrite Eggs around PkgForge

Force one build system onto the other

✅ Do

Layered integration

Optional backends

Shared schemas + conventions

Cross-project tooling


  1. Concrete integration points (the juicy part)

A. PkgForge as an optional package backend for Eggs

Add a new Eggs concept:

eggs package-backend:

  • apt
  • apk
  • pacman
  • pkgforge (NEW)

What this enables:

Eggs ISOs built entirely from pkgforge artifacts

Mixed sources (base OS + pkgforge apps)

Zero reliance on host distro repos

Implementation

Thin adapter in penguins-eggs

Calls:

pkgforge/bin

soar install

pkgcache pull

No deep coupling required.


B. Eggs → PkgForge build pipeline

Eggs already knows:

Exact package set

Versions

Architecture

Kernel + init + boot config

That’s gold.

New workflow

eggs produce manifest

PkgForge sbuilder

soar package set

bincache/store

Eggs ISO build

Artifacts become:

Reusable

Cacheable

Shareable across distros

This turns Eggs from “snapshot tool” into a reproducible OS factory.


C. penguins-packs ↔ soarpkgs

This is a near-perfect match.

Penguins-Packs PkgForge

Logical app groups Soar package collections
Role-based installs Declarative manifests
Desktop flavors App bundles

Action

Define a shared YAML/JSON schema

Auto-generate:

penguins-packs from soarpkgs

soarpkgs from penguins-packs

This avoids duplication and keeps both ecosystems in sync.


D. Eggs + squishy-rs + store.pkgforge.dev

Eggs outputs:

SquashFS

ISOs

Rootfs trees

PkgForge offers:

Optimized compression

Artifact storage

CDN distribution

Result

Eggs ISOs published via store.pkgforge.dev

Delta updates for Eggs remasters

Versioned OS images

That’s huge for bandwidth and CI.


  1. Alpine + non-Debian future

penguins-alpine + pkgforge/soar is where this gets spicy 🌶️

Alpine base

PkgForge apps

Eggs snapshot

Zero distro lock-in

You end up with:

A distro-agnostic OS builder

This positions Eggs way beyond Debian tooling.


  1. Collaboration model (this part matters)

Shared repos (new, small, neutral)

Suggested:

pkgforge-eggs-specs/
pkgforge-eggs-adapter/
eggs-pkgforge-manifests/

These should:

Be tiny

Be well-documented

Contain schemas + glue only

Maintainer boundaries

Eggs remains Eggs

PkgForge remains PkgForge

Integration lives between them

This avoids burnout and political friction.


  1. Suggested phased roadmap

Phase 1 (low risk, fast win)

Eggs → pkgforge binary cache

Manual integration

Proof-of-concept ISO

Phase 2

Package backend abstraction

Auto-generated manifests

CI builds using sbuilder-go

Phase 3

Store publishing

Delta ISOs

UI support in pengui


  1. What I can help you do next

If you want, I can:

Draft exact repo structure for the adapter

Write a PkgForge ↔ Eggs manifest spec

Sketch CLI commands (eggs pkgforge enable)

Prepare a maintainer-friendly pitch for both sides

Identify which repos should never be touched

Just tell me what you want to tackle first—and whether you want this framed as an experiment, addon, or long-term alliance.

This is one of the cleanest ecosystem fits I’ve seen in a while 👌 ]

Metadata

Metadata

Assignees

Labels

p3Low Priority (Maybe a while before it gets done/fixed)

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions